# Retrieve non-member booking restrictions

`GET /api/members/bookings-restrictions`

- **Success:** `200 OK`
- **Products:** Operator (`FOH`), Consumer (`CONSUMER`) (any one of these products, not all)
- **Features:** Online Bookings (`ONLINEBOOK`), Online Joining (`ONLINEJOIN`), Front of House Generic Access (`FOHGENERIC`) (any one of these features, not all)

HTML version: [Retrieve non-member booking restrictions](https://support.gladstonesoftware.cloud/reference/members/retrieve-non-member-booking-restrictions)

## Overview

Answers whether somebody with no member record — a walk-in, a guest, a visitor booking on the day — may book a particular activity. There is no person to identify here, so nothing about an account status or a subscription enters into it: the endpoint reads the activity alone, and the answer is the same for every non-member. Call it before you offer a guest booking, then use the booking endpoints.

The response reuses the member-restrictions shape, so `restrictions` still holds two entries. The first is a placeholder standing in for the status check that only a member can have; its `type` is the fixed string `Non member does not have any status` and it always passes. The second is the real check: an activity with no restriction configured is open to non-members, and an activity that is restricted is open to them only when the restriction names no subscription types. Where the restriction does name subscription types, a non-member cannot hold one, so the answer is no.

Reach for this one when the booking is for a guest with no account. Where you have an identified member, call `GET /api/members/{memberId}/bookings-restrictions` ("Retrieve member booking restrictions") instead — this endpoint would ignore their status and their subscriptions entirely, telling you what a stranger is allowed to do rather than what your customer is allowed to do, and a member who holds the right subscription can be refused here while passing there.

One difference in the fields themselves is worth knowing: `isActivityRestricted` on this endpoint reports whether the non-member failed the activity check, whereas on the member endpoint it reports whether the activity has a restriction configured at all. The two do not always agree.

## Endpoint

`GET {base_url}/api/members/bookings-restrictions`

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

## Query parameters

| Name | Type | Required | Description |
|------|------|----------|-------------|
| `activityId` | string | Yes | The activity to check. It is the only input the endpoint has, so it is required despite being a query parameter: omitting it or sending an empty value fails with `400`, and so does a value that matches no existing activity. |

## Sample request

```bash title="cURL"
curl -X GET '{base_url}/api/members/bookings-restrictions' \
  -H 'Authorization: Bearer {accessToken}' \
  -H 'X-Use-SSO: true'
```

## Response fields

| Field | Type | Description |
|-------|------|-------------|
| `memberAbleToProceed` | boolean | The overall verdict for any non-member: true when a person with no member record may book this activity. Because the status entry always passes, it is effectively the activity check's own result. |
| `activityId` | string | Echoes back the `activityId` you sent, so you can match a response to a request when checking several activities. |
| `isActivityRestricted` | boolean | True when the non-member failed the activity check — it is the inverse of the second entry in `restrictions`, not a statement about how the activity is configured. An activity that has a restriction configured with no subscription types therefore reports `false` here, even though a restriction exists. The member endpoint's field of the same name means something different. |
| `restrictions` | array of object | The individual checks behind `memberAbleToProceed`, always two entries: the non-member status placeholder first, then the activity check. |
| `restrictions[].type` | string | Which check the entry reports. The first is always the literal `Non member does not have any status`; the second is always the literal `Membership Restriction`. |
| `restrictions[].memberAbleToProceed` | boolean | The verdict for that one entry. The status placeholder is always `true`, since a non-member has no account status that could bar them. The `Membership Restriction` entry is `true` when the activity has no restriction configured, or has one that names no subscription types, and `false` when the restriction names subscription types — which a non-member cannot hold. |

## Sample response

```json title="200 OK"
{
  "memberAbleToProceed": true,
  "activityId": "string",
  "isActivityRestricted": true,
  "restrictions": [
    {
      "type": "string",
      "memberAbleToProceed": true
    }
  ]
}
```

## Errors

| Status | Meaning | When |
|--------|---------|------|
| `400` | Bad request | You sent no `activityId`, or an empty one — "No booking membership restrictions activity id provided." — or the value you sent matches no activity: "No activity found for the following activity Id: {activityId}.". |
| `500` | Internal server error | |