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)

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.

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

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

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

This page as markdown · All pages · llms.txt