# Get all form types

`GET /api/configuration/form-profile-types`

- **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: [Get all form types](https://support.gladstonesoftware.cloud/reference/configuration/get-all-form-types)

## Overview

Lists the form types available in the tenant. A form type identifies a place in a journey where an operator-designed form is used — sign-up, account management, and so on. Use it to label the `formTypeId` you get back from [the form profiles list](get-all-form-profiles.md), and as the filter value when narrowing that list.

**The `form` field is never populated by this endpoint.** Do not expect form definitions here; fetch an individual form profile to get those.

Unusually for this API, the two starter ids are fixed rather than allocated per tenant: `1` is always `SignUp` and `2` is always `AccountManagement`, in every tenant. That does **not** extend to any type an operator adds afterwards, whose id is allocated per tenant. If you need to branch on a type, match on `key` and treat `id` as a lookup result.

Results come back in no guaranteed order, and there is no filter and no paging — every form type is returned. When none exist you get `200` with an empty array `[]`.

## Endpoint

`GET {base_url}/api/configuration/form-profile-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/form-profile-types' \
  -H 'Authorization: Bearer {accessToken}' \
  -H 'X-Use-SSO: true'
```

## Response fields

| Field | Type | Description |
|-------|------|-------------|
| `[].id` | integer (int32) | The form type's identifier, and the value that appears as `formTypeId` on a form profile and as the `formTypeId` filter on the profiles list. The range is 0–255 despite the `int32` shown here. The two starter types carry fixed ids — `1` for sign-up and `2` for account management; ids for any type the operator adds later are allocated per tenant and are **not** portable between tenants. |
| `[].key` | string | The type's stable code name, such as `SignUp` or `AccountManagement`. Maximum 100 characters and never `null`. This is the value to match on if your integration needs to recognise a particular type: Gladstone itself identifies form types by it, and `key` is what translations are matched on, so it is the closest thing here to a constant. Nothing enforces case or uniqueness, so compare case-insensitively. |
| `[].description` | string | A human-readable explanation of where the form type is used — `Form used in sign up process`, for example. Maximum 255 characters and never `null`. Free text an operator can edit, so display it but never match on it; use `key` for that. It is the English text: any localised alternative arrives in `translation`. |
| `[].translation` | array of object | Localised overrides for the type's text, one entry per culture and per translated property, looked up by `key`. **Always present, and an empty array when no translations have been set up** — which is the default, so most tenants return `[]` here. Prefer the entry matching your user's culture and fall back to `description`. |
| `[].translation[].type` | string | Which property of the form type this entry translates. Because translations are held per property, several entries can share a culture — one for each translated property — so filter on both `culture` and `type` rather than taking the first match for a culture. Skip entries whose `type` you do not recognise. |
| `[].translation[].culture` | string | The culture this text is for, matching a `code` from [the available cultures list](get-all-available-cultures.md) — it always resolves to a real culture. Up to 20 characters, in the same lower-case form that endpoint returns (`en-gb`, `cy-gb`), which is **not** the mixed-case form a browser sends in `Accept-Language`. Lower-case both sides before matching. |
| `[].translation[].text` | string | The translated text itself, replacing whichever property `type` names. No length limit. Never `null` within an entry — an untranslated property has no entry at all rather than an entry with empty text. |
| `[].form` | array of object | **Never populated by this endpoint**, so it is always empty — it conveys no information and you should not branch on it. Form definitions live on individual form profiles; fetch a profile by its id to get one. |

## Sample response

```json title="200 OK"
[
  {
    "id": 12345,
    "key": "string",
    "description": "string",
    "translation": [
      {
        "type": "string",
        "culture": "string",
        "text": "string"
      }
    ],
    "form": []
  }
]
```

## Errors

| Status | Meaning | When |
|--------|---------|------|
| `500` | Internal server error | Any unexpected server-side failure while reading the form types or their translations — a malformed translation is a known cause of failures in this area. The response is a bare status code with **no body**. Retry with backoff. |