# Returns all medical condition types

`GET /api/configuration/medical-types`

- **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: [Returns all medical condition types](https://support.gladstonesoftware.cloud/reference/configuration/returns-all-medical-condition-types)

## Overview

Lists the medical condition types the operator has configured — the fixed vocabulary a member's medical record can draw on. Each entry is a label such as an allergy, a heart condition or a mobility restriction; the actual detail for an individual member is a separate record that points at one of these ids.

Call this to populate a picker before you create or update a member's medical condition, because `medicalConditionTypeId` on those calls must be an id from this list — an unrecognised id is rejected with `400` and the plain-text body `Medical condition type does not exist`.

**These ids are operator-defined, not platform constants.** Each tenant maintains its own list, so ids and descriptions differ between tenants and the same id can mean different things in two environments. Never hard-code them, and re-read the list rather than caching it across environments.

**Every configured type is returned, including inactive ones.** The endpoint applies no filter, so decide for yourself whether to hide `isActive` false entries — and note that the write endpoints do not filter either, so an inactive id is still accepted when creating a member's medical condition.

A create, update or delete made through this API shows up on your next request. A change made any other way can take up to six hours to appear here.

## Endpoint

`GET {base_url}/api/configuration/medical-types`

`{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/medical-types' \
  -H 'Authorization: Bearer {accessToken}' \
  -H 'X-Use-SSO: true'
```

## Response fields

| Field | Type | Description |
|-------|------|-------------|
| `[].id` | integer (int32) | The identifier to send as `medicalConditionTypeId` when you create or update a member's medical condition. Assigned by the platform when the type was created, unique within the tenant only — the same number means something different in another tenant's environment. |
| `[].typeDescription` | string | The operator's label for the condition type, and the only human-readable text on the record — there is no separate code, short name or translation. Maximum 50 characters and never null. Not guaranteed unique, so two types can share a description and only `id` distinguishes them. |
| `[].isActive` | boolean | Whether the operator still considers this type current. `false` types are retired for the purposes of your own UI, but nothing in the platform enforces that: they are returned by this endpoint and still accepted by the member medical condition write endpoints, which check only that the id exists. Filter on this yourself if you do not want to offer retired options. |

## Sample response

```json title="200 OK"
[
  {
    "id": 12345,
    "typeDescription": "string",
    "isActive": true
  }
]
```

## Errors

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