Unlink secondary member from primary member

DELETE /api/members/{primaryMemberId}/links/{secondaryMemberId}

Products: Operator (FOH), Consumer (CONSUMER) (any one of these products, not all)
Features: Online Joining (ONLINEJOIN), Online Bookings (ONLINEBOOK), Front of House Generic Access (FOHGENERIC) (any one of these features, not all)

Overview

Breaks the link between a primary member and one of the members linked to them, and removes that member's access to the primary's shared memberships.

This is a two-step operation performed on your behalf: the link is removed first, then the shared memberships are withdrawn. If the membership step fails, the link is restored and the whole call fails, so a failure normally leaves the member as they were. Where even the restore fails, the response is a 500 whose message says the rollback did not succeed — treat that as a state needing manual correction rather than something to retry blindly.

Nothing here deletes a member record. The secondary member keeps their account, their own memberships and their bookings; only the relationship and the shared access go.

Two rules are easy to trip over:

{primaryMemberId} really must be the primary of the pair. Passing them the other way round fails with 400, and your access token must match the primary member, not the secondary one.
A member below the tenant's age of consent cannot be unlinked — a junior's link is refused with 400, because a junior account is not permitted to stand alone.

If the primary has other links left afterwards they keep their primary status; if this was their last link, their own link settings are reset too.

Endpoint

DELETE {base_url}/api/members/{primaryMemberId}/links/{secondaryMemberId}

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

Path parameters

Name	Type	Required	Description
`primaryMemberId`	integer (int32)	Yes	The primary member of the link — the account the shared memberships belong to. Must match the member id in your access token, and must actually hold primary status, or the call fails with `400`.
`secondaryMemberId`	integer (int32)	Yes	The member being unlinked. Must be 1 or greater, must exist, and must currently be linked to `{primaryMemberId}` — a member linked to someone else returns `404`.

Sample request

cURL

curl -X DELETE '{base_url}/api/members/{primaryMemberId}/links/{secondaryMemberId}' \
  -H 'Authorization: Bearer {accessToken}' \
  -H 'X-Use-SSO: true'

Errors

A successful call returns 204 No Content.

Status	Meaning	When
`400`	Bad request	`{secondaryMemberId}` is 0 or negative: `Cannot be called with non or purged member record`
`400`	Bad request	`{primaryMemberId}` is not a primary member — usually the two ids the wrong way round: `Called successfully but member {primaryMemberId} is not a primary member`
`400`	Bad request	The member being unlinked is below the age of consent: `Called successfully but member {secondaryMemberId} is a junior member`
`400`	Bad request	The link was removed but the shared memberships could not be, and the link has been restored. The message is the one returned by the membership step.
`404`	Not found	Either member does not exist: `Called successfully but member {primaryMemberId} does not exist`, `Called successfully but linked member ID {secondaryMemberId} does not exist`
`404`	Not found	The two members are not linked to each other: `Called succesfully but linked member ID {secondaryMemberId} is not linked to primary member with ID {primaryMemberId}` (the typo is in the platform)
`500`	Internal server error	The membership removal failed and the link could not be restored — the message ends `Operation rollback failed: …` and the member is left unlinked but still holding shared memberships. Do not retry; reconcile the state first.
`500`	Internal server error	Part of the platform needed for the unlink was unreachable, or another unexpected server-side failure occurred.

This page as markdown · All pages · llms.txt