Retrieve member booking restrictions

GET /api/members/{memberId}/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 one question before you start a booking: may this member book, and — when you name an activity — do their memberships satisfy the restriction the operator has placed on it. It books nothing and changes nothing, so it is safe to call as often as you need while a customer is choosing.

Two checks run, and both are returned in restrictions so you can tell which one failed:

Status. The member's account status is compared against the statuses the operator has barred from booking. This check runs whether or not you send an activityId.
Membership. When the activity has a restriction configured against it, the member must hold a subscription of one of the types that restriction permits, and that subscription must be current today — today must fall between its start and end dates. An activity with no restriction configured passes automatically.

The top-level memberAbleToProceed is true only when both checks pass. Omit activityId and only the status check is really performed: the membership entry is filled in as a pass regardless, and isActivityRestricted comes back false because there was no activity to look at.

Use this endpoint when the person booking has a member record you can identify, because everything it does depends on reading that member's status and subscriptions. For a walk-in or guest with no member record, call GET /api/members/bookings-restrictions ("Retrieve non-member booking restrictions") instead, which takes the activity alone. The two are not interchangeable in either direction: the non-member endpoint performs no status check at all, so pointing it at an activity on behalf of a member whose status bars them from booking will still answer yes.

Endpoint

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

{base_url} is the environment URL issued to your integration. See Authenticating with Gladstone APIs.

Path parameters

Name	Type	Required	Description
`memberId`	integer (int32)	Yes	The member being checked; their status and their subscriptions are what the endpoint reads. Existence is only verified when the value is greater than `0`, so do not rely on `0` or a negative id coming back as a clean `404`.

Query parameters

Name	Type	Required	Description
`activityId`	string	No	The activity to check the member against — the same activity identifier the past-bookings endpoints return. Send it whenever you are validating a specific booking: omit it and the membership check is skipped and reported as a pass, which makes the response say nothing about any particular activity. When you do send it, it must match an existing activity or the call fails with `400`.

Sample request

cURL

curl -X GET '{base_url}/api/members/{memberId}/bookings-restrictions' \
  -H 'Authorization: Bearer {accessToken}' \
  -H 'X-Use-SSO: true'

Response fields

Field	Type	Description
`memberAbleToProceed`	boolean	The overall verdict, and the only field you need for a yes/no decision. True only when both entries in `restrictions` are true — the member's status is not barred, and their memberships satisfy the activity's restriction. Read `restrictions` to explain a `false` to the customer.
`activityId`	string	Echoes back the `activityId` you sent. Absent or empty when you did not send one, which is your signal that the membership check was not really performed.
`isActivityRestricted`	boolean	True when the activity has a restriction configured against it at all, regardless of this member — a member who holds the right subscription can still see `true` here alongside `memberAbleToProceed: true`. It is `false` when you omit `activityId`, because there was no activity to check, not because the activity is open to everyone.
`restrictions`	array of object	The individual checks behind `memberAbleToProceed`, always two entries: the member's status check first, then the membership check.
`restrictions[].type`	string	Which check the entry reports. The first entry carries the member's own status value as its type, so the string varies by member and by operator configuration. The second is always the literal `Membership Restriction`.
`restrictions[].memberAbleToProceed`	boolean	The verdict for that one check. On the status entry, `false` means the member's status is one the operator has barred from booking. On the membership entry, `false` means the activity is restricted and the member holds no subscription of a permitted type that is current today; it is `true` when the activity has no restriction, and also `true` unconditionally when you omitted `activityId`.

Sample response

200 OK

{
  "memberAbleToProceed": true,
  "activityId": "string",
  "isActivityRestricted": true,
  "restrictions": [
    {
      "type": "string",
      "memberAbleToProceed": true
    }
  ]
}

Errors

Status	Meaning	When
`400`	Bad request	The `activityId` you supplied does not match any activity — "No activity found for the following activity Id: {activityId}.". Omitting `activityId` altogether is allowed and does not raise this.
`404`	Not found	No member holds the supplied id — "Invalid Member ID {memberId}: member doesn't exist". Only checked when `memberId` is greater than `0`.
`500`	Internal server error

This page as markdown · All pages · llms.txt