Get all form profiles
GET /api/configuration/form-profiles
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 profiles configured for the tenant. A form profile is a named, operator-designed form definition — the set of fields, labels and rules used at a particular point in a journey, such as the sign-up form or the account-details form. Each profile belongs to exactly one form type, which is what says where in the journey it is used.
This list is an index, not the forms themselves. Every profile has a JSON field definition, and it is not included here — you get the id, the type and the name only. To render or validate a form you must fetch the individual profile by its formProfileId. Use this endpoint to discover which profiles exist, then fetch the one you need.
Use formTypeId to narrow the list to one part of the journey. Filtering by a type that has no profiles, or does not exist at all, returns 200 with an empty array [] rather than a 404 — the type is not checked for existence first.
Results come back in no guaranteed order, and there is no paging and no active/inactive flag: every profile the operator has created is returned, whether or not their app currently uses it.
Endpoint
GET {base_url}/api/configuration/form-profiles
{base_url} is the environment URL issued to your integration. See Authenticating with Gladstone APIs.
Query parameters
| Name | Type | Required | Description |
|---|---|---|---|
formTypeId | integer (int32) | No | Restricts the list to profiles belonging to one form type — pass an id from the form types list. Omit it to return every profile of every type; there is no way to ask for several types in one call, so repeat the request or filter client-side. The accepted range is 0–255 despite the int32 shown here: send 256 or more, or a negative number, and the request is rejected with a 400. A well-formed id that matches nothing yields an empty array, not an error. |
Sample request
curl -X GET '{base_url}/api/configuration/form-profiles' \
-H 'Authorization: Bearer {accessToken}' \
-H 'X-Use-SSO: true'Response fields
| Field | Type | Description |
|---|---|---|
[].formProfileId | integer (int32) | The profile's identifier, and the value you pass to the single-profile endpoint to retrieve the form definition itself. Allocated per tenant, so it is specific to one tenant — never hard-code it, and expect gaps where profiles have been deleted. |
[].formTypeId | integer (int32) | The form type this profile belongs to, matching an id from the form types list and the value the formTypeId filter takes. Required on every profile and always a real type. Range 0–255. Unusually for this API, the two starter type ids are fixed rather than allocated per tenant, so 1 (sign-up) and 2 (account management) mean the same thing in every tenant — but an operator can add types of their own beyond those, and those additional ids are not portable. |
[].formProfileName | string | The operator's name for the profile, for display in a picker. Maximum 100 characters and never null. Free text with no uniqueness constraint, so two profiles of the same type can share a name — match on formProfileId, never on this. Note that the profile's actual field definition is not part of this response; the name is all the detail you get here. |
Sample response
[
{
"formProfileId": 12345,
"formTypeId": 12345,
"formProfileName": "string"
}
]Errors
| Status | Meaning | When |
|---|---|---|
400 | Bad request | formTypeId is invalid — it was not a whole number, or it fell outside the 0–255 range the parameter accepts. The response is a validation problem document (application/problem+json) naming the parameter, rather than the bare body the other failures return. |
500 | Internal server error | Any unexpected server-side failure while reading the form profiles. The response is a bare status code with no body. Retry with backoff. |