Get form profile by ID

GET /api/configuration/form-profiles/{formProfileId}

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)

Overview

A form profile is an operator-defined description of a member-facing form: which sections appear, and which fields inside each section are shown. Operators maintain them so that the sign-up and account-management screens can be changed without a code release. Call this endpoint when you are about to render one of those forms, and build your UI from what comes back rather than hardcoding a field list.

The response is not the operator's configuration verbatim. It is expanded into a fixed structure of exactly eight sections, always present and always in the same order: profileDetails, contactDetails, addressDetails, medicalDetails, userFields, emergencyDetails, vehicleDetails, acceptanceDetails. Sections are never omitted — a section the operator has switched off arrives with display: false, so read display rather than testing for the key.

Only two kinds of form can be expanded: sign-up (formTypeId 1) and account management (formTypeId 2). A profile set up for any other form type is a configuration fault and fails with 500 rather than a 400 you could act on.

formProfileId is a tenant-scoped integer — profile 4 on one operator's system is an unrelated profile on another's, so never hardcode it or carry it between environments. Get valid ids from Get all form profiles, which also lets you filter by form type. A formProfileId that does not exist returns 404 with a plain-text message body, not an empty 200.

There is no active or retired flag on a form profile and the lookup applies no filter, so every profile the operator has ever created is retrievable and none of them are hidden from you. If an operator has superseded a profile, nothing in this response tells you so.

The optional membershipTypeIds filter affects only the userFields section. It never removes a section, and it never touches the built-in fields in the other seven sections. See the parameter description for the exact matching rule.

Endpoint

GET {base_url}/api/configuration/form-profiles/{formProfileId}

{base_url} is the environment URL issued to your integration. See Authenticating with Gladstone APIs.

Path parameters

Name	Type	Required	Description
`formProfileId`	integer (int32)	Yes	The form profile to retrieve, as allocated by the platform when the operator created it. Tenant-scoped and not portable between operators or environments — take it from Get all form profiles rather than hardcoding it. An id that matches no profile returns `404`; a value that is not a valid 32-bit integer returns `400` before the lookup runs.

Query parameters

Name	Type	Required	Description
`membershipTypeIds`	string	No	Restricts the `userFields` section to the custom fields that apply to the membership types you name — use it when you already know which package the member is joining on, so you only render the fields relevant to it. Supply membership type ids as a comma-separated list, for example `ADULT,STUDENT`; these are the operator-defined ids returned by List membership types. Before splitting, the endpoint strips every space and every `[` and `]` character from the value, so `[ADULT, STUDENT]` and `ADULT, STUDENT` are both accepted — but a membership type id that itself contains a space or a bracket can never be matched. A user field survives the filter if at least one of the membership type ids attached to it is an exact string match for at least one value you supplied; a user field with no membership types attached is dropped. Omit the parameter, or send it empty, and no filtering happens at all — every user field is returned, and the other seven sections are unaffected either way.

Sample request

cURL

curl -X GET '{base_url}/api/configuration/form-profiles/4?membershipTypeIds=ADULT,STUDENT' \
  -H 'Authorization: Bearer {accessToken}' \
  -H 'X-Use-SSO: true'

Response fields

Field	Type	Description
`formProfileId`	integer (int32)	Echo of the `{formProfileId}` you requested. Useful when you fan out several calls and need to match responses to requests.
`formTypeId`	integer (int32)	Which member-facing form this profile configures: `1` is the sign-up form and `2` is the account-management form. These are the only two values you can receive from a successful call — a profile set up for any other form type fails with `500` rather than returning. Resolve the id to the operator's label with Get all form types.
`formProfileName`	string	The operator's own name for the profile, such as the package or journey it belongs to. At most 100 characters and always required, so it is never null or empty. It is a management label, not something intended for display to members.
`form`	array of object	The expanded form definition: always exactly eight section objects, always in the order `profileDetails`, `contactDetails`, `addressDetails`, `medicalDetails`, `userFields`, `emergencyDetails`, `vehicleDetails`, `acceptanceDetails`. Index into it by matching `sectionName`, not by position, so that a future reordering does not break you.
`form[].sectionName`	string	Identifies which section this entry is, as one of the eight camelCase names listed above. Use it as the key when mapping sections onto your own screens.
`form[].display`	boolean	Whether the operator wants this section rendered at all. `false` means suppress the whole section — its `fields` are still present in the response, so ignoring `display` will show sections the operator has switched off. Defaults to `true` when the configuration does not mention the section's display setting.
`form[].fields`	object or array	Which fields inside the section to render, and its shape depends on the section. For the seven built-in sections it is an object of boolean flags — for example `profileDetails` carries `title`, `firstName`, `lastName`, `gender`, `email` and `dateOfBirth` — where `true` means show the field and a flag absent from the configuration defaults to `true`. `medicalDetails`, `emergencyDetails` and `vehicleDetails` have no per-field flags at all, so their `fields` is always an empty object and `display` is the only control you get for them. For `userFields` it is instead an array, described below.
`form[].fields[].id`	integer (int32)	`userFields` only. The identifier of a custom field the operator has defined, which you match against the user field configuration to learn its label and data type.
`form[].fields[].membershipTypeIds`	array of string	`userFields` only. The membership types this custom field applies to, as operator-defined ids. When you pass `membershipTypeIds` on the request, a field is kept only if one of these values matches one of yours exactly. Returned as an empty array when the field is not restricted to any membership type — note that such a field is dropped by the filter rather than treated as applying to all types, so filtering can hide fields you would otherwise show.

Sample response

200 OK

{
  "formProfileId": 4,
  "formTypeId": 1,
  "formProfileName": "Online join - adult",
  "form": [
    {
      "sectionName": "profileDetails",
      "display": true,
      "fields": {
        "title": true,
        "firstName": true,
        "lastName": true,
        "gender": false,
        "email": true,
        "dateOfBirth": true
      }
    },
    {
      "sectionName": "contactDetails",
      "display": true,
      "fields": { "mobile": true, "telephone1": false, "telephone2": false }
    },
    {
      "sectionName": "addressDetails",
      "display": true,
      "fields": {
        "addressSearch": true,
        "addressLine1": true,
        "addressLine2": true,
        "addressLine3": false,
        "townCity": true,
        "region": false,
        "postalCode": true,
        "country": true
      }
    },
    {
      "sectionName": "medicalDetails",
      "display": false,
      "fields": {}
    },
    {
      "sectionName": "userFields",
      "display": true,
      "fields": [
        { "id": 12, "membershipTypeIds": ["ADULT", "STUDENT"] }
      ]
    },
    {
      "sectionName": "emergencyDetails",
      "display": true,
      "fields": {}
    },
    {
      "sectionName": "vehicleDetails",
      "display": false,
      "fields": {}
    },
    {
      "sectionName": "acceptanceDetails",
      "display": true,
      "fields": { "optInMarketing": true, "signedAgreements": true }
    }
  ]
}

Errors

Status	Meaning	When
`400`	Bad request	The `{formProfileId}` route segment is not a valid 32-bit integer. The request is rejected before the lookup runs, and the body is a validation problem document (`application/problem+json`) with an `errors` map keyed by field name.
`404`	Not found	No form profile exists with that id in this tenant. The body is the plain string `A form profile with the ID {formProfileId} could not be found`. This is the response for a deleted or mistyped id — you never receive an empty `200` in its place.
`500`	Internal server error	The profile exists but its `formTypeId` is neither `1` (sign-up) nor `2` (account management), so the endpoint has no way to expand it. This is an operator configuration fault that you cannot fix from the client; report the `formProfileId` to the operator.
`500`	Internal server error	The profile's form definition cannot be expanded — the definition is malformed, one of the eight expected sections is missing from it, or a field flag holds a non-boolean value. Again a configuration fault rather than a client error, and re-requesting will keep failing until the operator corrects the profile.
`500`	Internal server error	Any other unexpected server-side failure while reading. All three `500` cases return a bare status code with no response body, so there is nothing to parse and nothing that distinguishes them on the wire; quote the `formProfileId` and the time of the call when raising a ticket.

This page as markdown · All pages · llms.txt