Create booking membership restrictions

POST /api/configuration/bookings/restrictions/memberships

Success: 201 Created

• Products: Operator (FOH)
• Features: Front of House Generic Access (FOHGENERIC)

Overview

Creates one booking membership restriction — a named rule that ties a set of activities to a set of membership types. The rule says that the named activities may be booked only by a member holding a subscription of one of the named types, and only while that subscription is current (today falls between its start and end dates). An activity that appears on no restriction stays open to everyone.

The rule is advisory, not enforced at the point of booking. The restrictions are applied only by the pre-booking check — Retrieve member booking restrictions for an identified member. Creating a booking does not consult them. If your integration does not call the check and honour memberAbleToProceed before it books, the restriction you configure here has no effect on what actually gets booked.

Both lists are written in the same call — you cannot create the restriction first and attach activities or membership types afterwards. To change either list later, replace the restriction with Update booking membership restrictions.

The identifier is generated by the system; you cannot supply or choose it. It comes back in the response body as bookingMembershipRestrictionId. The 201 response sets an empty Location header, so read the identifier from the body and keep it — it is what you quote to Get booking membership restrictions by ID and Delete booking membership restrictions.

Nothing about the restriction is unique, and the call is not idempotent. No check is made against restrictions that already exist, so sending the same body twice creates a second, independent restriction with its own identifier, and the same description, activity or membership type may appear on any number of restrictions. A retry after a timeout duplicates the rule rather than returning 409. List the restrictions with Get all booking membership restrictions before retrying.

Where an activity appears on more than one restriction, a member gets through if any one of those restrictions names a membership type they currently hold. Multiple restrictions on the same activity widen access rather than compounding into an "all of" rule.

One failure mode is worth guarding against. The restriction, its activities and its membership types are saved in three separate steps, not as a single all-or-nothing operation. If the call fails part-way and returns 500, a restriction can survive that names activities but no membership types — and because the activity is now restricted while no membership type satisfies it, the pre-booking check fails for every member against those activities. After any 500, list the restrictions and delete the incomplete one.

Endpoint

POST {base_url}/api/configuration/bookings/restrictions/memberships

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

Request body

Sample request

curl -X POST '{base_url}/api/configuration/bookings/restrictions/memberships' \
  -H 'Authorization: Bearer {accessToken}' \
  -H 'X-Use-SSO: true' \
  -H 'Content-Type: application/json' \
  -d '{
  "description": "string",
  "activities": [
    "string"
  ],
  "memberships": [
    "string"
  ]
}'

Response fields

Sample response

{
  "bookingMembershipRestrictionId": 12345
}

Errors

Validation failures return a plain JSON string containing the message shown below, not a problem document. The exception is a malformed body, which returns a validation problem document (application/problem+json) with an errors map keyed by field name.

This page as markdown · All pages · llms.txt