# Getting started

> How the API reference is organised, how to read an endpoint page, and what to set up before your first call.

HTML version: [Getting started](https://support.gladstonesoftware.cloud/reference/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](../guides/getting-started.md) 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](../guides/authenticating-with-gladstone-apis.md) first — it
explains the two authentication methods and which one to choose. For new integrations the
recommended route is [API Key Authentication](../guides/api-key-authentication.md).

Two more pages are worth reading before you write code:

- [Glossary](../guides/glossary.md) — 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](../guides/rate-limiting.md) — 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.