# Retrieves all site facilities with their configuration details

`GET /api/configuration/site-facilities`

- **Success:** `200 OK`
- **Products:** Operator (`FOH`), Consumer (`CONSUMER`) (any one of these products, not all)
- **Features:** Online Joining (`ONLINEJOIN`), Front of House Generic Access (`FOHGENERIC`) (any one of these features, not all)

HTML version: [Retrieves all site facilities with their configuration details](https://support.gladstonesoftware.cloud/reference/configuration/retrieves-all-site-facilities-with-their-configuration-details)

## Overview

Lists every facility defined in the environment — the vocabulary of physical spaces a site can advertise, such as a pool, a gym or a squash court. This is the master list, not a per-site list: it tells you which facilities exist and what each is called, but not which sites have them.

**A facility here is descriptive, not bookable.** These records exist so a site can say what it has; they are not the resources you reserve against. Bookable things are activities and resources, reached through the activity and booking endpoints, and a facility record carries no capacity, opening hours or availability. Do not try to build a booking flow on these ids.

To find the facilities at a particular site, read the site instead — [Get site by id](get-site-by-id.md) and [Get all sites with optional filtering](get-all-sites-with-optional-filtering.md) return each site's mapped facilities inline, with the same fields and translations you see here. Use this endpoint when you need the whole vocabulary up front, for example to render a site-finder filter.

**Facilities are read-only through the API.** There is no create, update or delete endpoint for a facility; the list is maintained by Gladstone. What a tenant controls is which sites each facility is mapped to, through the site endpoints.

Every facility is returned. There is no active or visible flag on a facility and no filter is applied, so nothing is hidden and nothing needs paging.

## Endpoint

`GET {base_url}/api/configuration/site-facilities`

`{base_url}` is the environment URL issued to your integration. See [Authenticating with Gladstone APIs](../../guides/authenticating-with-gladstone-apis.md).

## Sample request

```bash title="cURL"
curl -X GET '{base_url}/api/configuration/site-facilities' \
  -H 'Authorization: Bearer {accessToken}' \
  -H 'X-Use-SSO: true'
```

## Response fields

| Field | Type | Description |
|-------|------|-------------|
| `[].id` | integer (int32) | The facility's numeric identifier. It is what the site write endpoints expect when you map a facility to a site, but it is not the key the platform joins translations on — see `facilityKey`. Do not treat it as portable between environments. |
| `[].facilityKey` | string | The facility's stable code, maximum 50 characters, required and **unique across the whole list** — the only field here with a uniqueness guarantee. It is also the value translations are stored against, so `facilityKey`, not `id`, is what you match on if you need to recognise a specific facility in your own code. |
| `[].name` | string | The facility's display label in the environment's base language, maximum 100 characters and never null. Not unique — two facilities can share a name, so key on `facilityKey`. For a localised interface, look for a `translations` entry with `type` `Name` and the culture you want, and fall back to this value when none exists. |
| `[].description` | string | Longer explanatory text about the facility, up to 255 characters. Optional, so `null` where none was recorded. Localised the same way as `name`, through a `translations` entry with `type` `Description`. |
| `[].translations` | array of object | Localised variants of this facility's text fields, looked up by `facilityKey`. **Always present, and an empty array `[]` when nothing has been translated** — never null. Each entry translates one property into one culture, so a facility with a translated name and description in two languages yields four entries. Coverage is not guaranteed: a culture may be present for `Name` and absent for `Description`, so always fall back to the base `name` and `description`. Translations are maintained through the translation endpoints, not by any facility endpoint. |
| `[].translations[].type` | string | Which property of the facility this entry translates, matching the field name — `Name` or `Description`. Maximum 50 characters. It is stored verbatim from whatever the translation import supplied, so treat an unrecognised value as data to ignore rather than a field you have missed. |
| `[].translations[].culture` | string | The culture the `text` is written in, maximum 20 characters, in the form the environment's translation data uses. Compare it against the cultures returned by [Get all available cultures](get-all-available-cultures.md) rather than assuming a fixed set, and do not assume every culture is present for every facility. |
| `[].translations[].text` | string | The translated value itself, to be used in place of the base `name` or `description` for the matching `culture`. Unbounded length. |

## Sample response

```json title="200 OK"
[
  {
    "id": 12345,
    "facilityKey": "string",
    "name": "string",
    "description": "string",
    "translations": [
      {
        "type": "string",
        "culture": "string",
        "text": "string"
      }
    ]
  }
]
```

## Errors

| Status | Meaning | When |
|--------|---------|------|
| `200` | OK | Success. An environment with no facilities defined returns `200` with an empty JSON array `[]`, not `204`. |
| `500` | Internal server error | An unexpected server-side failure reading the list or its translations. The response has no body. There is no request input to correct, so retry rather than adjust the call. |