# 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)

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

## 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](../../guides/authenticating-with-gladstone-apis.md).

## 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

```bash title="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

```json title="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 | |