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)

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, 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.

Sample request

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 — 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

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.

This page as markdown · All pages · llms.txt