Confirm a previously unconfirmed member creation

POST /api/members/{memberId}/confirm

Products: Operator (FOH)
Features: Front of House Generic Access (FOHGENERIC)

Overview

Marks a member record that was created in a pending state as complete, so that the member is no longer treated as an abandoned sign-up. A member created with pendingConfirmation set is held provisionally and is a candidate for automatic deletion; this call clears that flag and is the step that stops the record being cleaned up.

This is the final step of a multi-call sign-up. Make it only after every other part of the sign-up has succeeded — once you have confirmed a member you cannot un-confirm them through this API. Confirming also triggers the business rules that were skipped at creation time, including publishing the internal "new member" notification, so it is not a purely cosmetic flag flip.

The call is single-use rather than idempotent. On success it returns 204 No Content and clears the pending flag. A second call against the same member returns 400, because the member is no longer pending confirmation — a 400 here therefore usually means "already done", not "your request was malformed". Use it to distinguish a repeat from a genuine failure.

The flag is cleared and saved before the new-member notification is sent, and both happen inside the same error handler. If the notification fails you receive 500 even though the member has already been confirmed, so do not retry blindly on 500 — re-read the member first.

You do not normally need to call this endpoint when using Create a new linked member for a primary member; that endpoint confirms the member it creates as its own last step.

Endpoint

POST {base_url}/api/members/{memberId}/confirm

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

Path parameters

Name	Type	Required	Description
`memberId`	integer (int32)	Yes	The member whose provisional creation you are completing. This must be a member that is currently pending confirmation — a member that exists but has already been confirmed is rejected with `400`, and an id that matches no member is rejected with `404`. It must also be a real member id: `0` and negative ids (such as the ids left behind by purged members) are rejected with `400` before any lookup happens.

Sample request

cURL

curl -X POST '{base_url}/api/members/{memberId}/confirm' \
  -H 'Authorization: Bearer {accessToken}' \
  -H 'X-Use-SSO: true'

Errors

Status	Meaning	When
`400`	Bad request	The member exists but is not pending confirmation — most often because you have already confirmed them. The message reads `Member ID {memberId} is not pending confirmation.` and the member is left unchanged.
`400`	Bad request	`memberId` is not a usable member id. A non-member id returns `0 is an invalid member id`, a purged member id returns `-999 is an invalid member id`, and a value that is not an integer at all is rejected by model binding with `the value 'invalidid' is not valid`.
`401`	Unauthorized	The request carries an anonymous token rather than a member token. The member is left pending confirmation.
`404`	Not found	No member exists with this id. The message reads `Member ID {memberId} was not found.`
`500`	Internal server error	The member lookup, the save, or the new-member notification threw. Note that the notification is sent after the pending flag has been saved, so a `500` does not guarantee the member is still pending — check the member's state before retrying.

This page as markdown · All pages · llms.txt