Getting started
This section documents the Gladstone GO platform API endpoint by endpoint. Every page here covers exactly one endpoint and is self-contained: you should never need a second page open to understand the one you are reading.
If you are building an integration from scratch, start with the integration guides instead. The guides walk through complete flows — joining, booking, taking payment — and link out to the reference pages for each call. Come here when you know which call you need and want its fields, constraints and failure modes.
Before your first call
Every endpoint requires a bearer token. Read Authenticating with Gladstone APIs first — it explains the two authentication methods and which one to choose. For new integrations the recommended route is API Key Authentication.
Two more pages are worth reading before you write code:
- Glossary — the platform uses terms from the leisure industry, and several of them look like ordinary English words while meaning something specific. Read this before your first integration, not after your first confusing response.
- Restrictions — rate limits and other platform restrictions that your integration has to handle rather than discover in production.
What is documented here
This reference covers the endpoints available to third-party partner integrations. Endpoints that are internal to Gladstone products are deliberately not listed, so if you have seen a call made by one of our own applications and cannot find it here, it is not available to you.
How to read an endpoint page
Every endpoint page uses the same fixed set of sections, always in this order. Sections that do not apply to a given endpoint are omitted rather than left empty.
| Section | What it tells you |
|---|---|
| Overview | What the endpoint does, when to reach for it, and where it sits in a larger flow. |
| Endpoint | The HTTP method and path. |
| Path parameters | Values embedded in the URL. |
| Query parameters | Values in the query string, including filters and paging. |
| Request headers | Headers beyond the standard Authorization. |
| Request body | The request payload, field by field. |
| Response fields | The response payload, field by field. |
| Sample request | A complete, runnable example. |
| Sample response | A real response body, labelled with its status code. |
| Errors | What actually triggers each status code on this endpoint. |
| Notes | Anything that does not fit above — ordering constraints, caveats, known quirks. |
Conventions
Nested fields use dotted paths. A field written as bookings[].pricingQuote.totalPrice.amount
is amount, inside totalPrice, inside pricingQuote, on each element of the bookings array.
Nested objects are flattened into one table this way rather than split across several.
Required means required by the API, not merely conventional. Where a field is optional, the
description says what happens when you omit it — whether there is a default, whether omission
means "no change", or whether it means "remove".
Where a value has to come from somewhere, the description says where. Opaque identifiers such as lease and slot references are only meaningful if you know which earlier call returned them, so those descriptions link back to that call.
The Errors table gives real triggers. Each row describes a specific cause on that endpoint rather than a generic restatement of the status code. Where a request can fail partially — some items in a batch succeeding while others do not — the table says so explicitly. Do not assume all-or-nothing behaviour unless the page states it.
Gaps are marked, not filled. Where our own sources do not answer a question, the page leaves an explicit marker rather than a plausible-sounding guess. If a field you need is undocumented, raise it with us — do not infer its behaviour from its name.
The groups
The reference is divided into the groups below, listed in the sidebar in this order. Expand a group there to see its endpoints.
| Group | Covers |
|---|---|
| Configuration | Account setup — member options, activities, products and financial configuration. |
| Members | Retrieve and update member profiles, payment details and membership data. |
| Bookings | Availability, leases, booking creation and booking management. |
| Joining | The membership purchase flow. |
| Payments | Taking payment for bookings and memberships. |
| Communications | Configuring and sending communications to members. |
| Digital Passes | Wallet passes for bookings and memberships. |
| Access Control | Managing physical access to sites. |
| Users | Staff access and leisure centre personnel management. |
Searching is usually faster than browsing: the search box matches endpoint titles, paths and body text across the reference, the guides and the knowledge base at once.