# Create booking status restrictions

`POST /api/configuration/bookings/restrictions/status`

- **Success:** `200 OK`
- **Products:** Operator (`FOH`)
- **Features:** Front of House Generic Access (`FOHGENERIC`)

HTML version: [Create booking status restrictions](https://support.gladstonesoftware.cloud/reference/configuration/create-booking-status-restrictions)

## Overview

Bars one or more member account statuses from booking. A member status is the code on a member's record that says where they stand with the operator — for example current, suspended or lapsed. Every status you add here goes on a block list: a member whose status appears on that list fails the pre-booking check, whatever they are trying to book.

**The block list is advisory, not enforced at the point of booking.** It is applied only by the pre-booking check — [Retrieve member booking restrictions](../members/retrieve-member-booking-restrictions.md), which reports the member as unable to proceed when their status is listed. Creating a booking does not consult the list. If your integration does not call the check and honour `memberAbleToProceed`, adding a status here changes nothing about what actually gets booked.

The request is a batch: send as many status entries as you like in one call. Validation runs over the whole batch first and nothing is saved until every entry passes, so a rejected batch leaves the block list untouched — there is no partial application.

**No identifier comes back.** On success the endpoint returns `200 OK` with the literal JSON body `true`, not `201` and not the created entries. Each entry's identifier is generated for you but never returned, so to find the `id` you need for [Delete booking status restrictions](delete-booking-status-restrictions.md) you must list the block list afterwards with [Get all booking status restrictions](get-all-booking-status-restrictions.md).

**The call is not idempotent and nothing is unique.** No check is made for a status that is already blocked, and statuses are not required to be unique, so sending the same body twice adds a second entry for the same status rather than returning `409`. The duplicate does not change behaviour — the check only asks whether the status appears at all — but each duplicate entry has to be deleted individually. After a timeout, list the block list before retrying.

## Endpoint

`POST {base_url}/api/configuration/bookings/restrictions/status`

`{base_url}` is the environment URL issued to your integration. See [Authenticating with Gladstone APIs](../../guides/authenticating-with-gladstone-apis.md).

## Request body

| Field | Type | Required | Description |
|-------|------|----------|-------------|
| `bookingsStatusRestrictions` | array of object | Yes | The statuses to add to the block list, one entry per status. Required in practice even though it is not marked as required: an absent, null or empty array is rejected with `400` before anything is written. There is no documented ceiling on the number of entries, and all entries are saved together in one operation. |
| `bookingsStatusRestrictions[].restrictionId` | integer (int32) | Yes | Saved with the entry and echoed back by the status-restriction `GET` endpoints, but has no other effect — it does not refer to any other resource and nothing filters on it. Despite the `integer (int32)` shown here, only **0 to 255** is accepted; anything larger is rejected with `400`. Zero is rejected explicitly, and omitting the field is treated as zero and produces that same rejection — so you must send a value between 1 and 255. |
| `bookingsStatusRestrictions[].statusId` | string | Yes | The member status code to block, up to 15 characters — the `id` values returned by [Get all member statuses](get-all-member-statuses.md). Each one is looked up before anything is written and a code that matches no status fails the whole batch with `400`. Omitting it or sending `null` is rejected with a validation problem document before any other check runs. Statuses are reference data and are not created for you — use [Creates a status](creates-a-status.md) if the code you need does not exist yet. |

## Sample request

```bash title="cURL"
curl -X POST '{base_url}/api/configuration/bookings/restrictions/status' \
  -H 'Authorization: Bearer {accessToken}' \
  -H 'X-Use-SSO: true' \
  -H 'Content-Type: application/json' \
  -d '{
  "bookingsStatusRestrictions": [
    {
      "restrictionId": 1,
      "statusId": "string"
    }
  ]
}'
```

## Sample response

```json title="200 OK"
true
```

## Errors

Failures come back as a plain JSON string holding the message below, not a problem document. The exception is a malformed or incomplete body, which returns a validation problem document (`application/problem+json`) with an `errors` map keyed by field name.

| Status | Meaning | When |
|--------|---------|------|
| `400` | Bad request | The body is missing, is not valid JSON, `statusId` is absent or null, or `restrictionId` is outside the 0–255 range. The request is rejected before any other check runs, with a validation problem document (`application/problem+json`) whose `errors` map is keyed by field name. |
| `400` | Bad request | `bookingsStatusRestrictions` is absent, null or an empty array — `Invalid request: No booking status restrictions provided.` |
| `400` | Bad request | An entry names a status code that does not exist — `Status with ID '{statusId}' not found.` The whole batch is rejected. |
| `400` | Bad request | An entry has `restrictionId` of `0`, which is also what you get by omitting it — `Invalid request: No booking restriction id provided with status ID '{statusId}'.` The whole batch is rejected. |
| `404` | Not found | This endpoint does not return `404` for anything in your payload. Treat a `404` here as a routing problem rather than something about your payload. |
| `500` | Internal server error | An unexpected server-side failure. The batch is saved in a single operation, so a `500` means no entries were added. |