# Remove shared membership access between linked members

`DELETE /api/members/{primaryMemberId}/memberships/linked-memberships/{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)

HTML version: [Remove shared membership access between linked members](https://support.gladstonesoftware.cloud/reference/members/remove-shared-membership-access-between-linked-members)

## Overview

Undoes [Apply shared memberships to linked member](apply-shared-memberships-to-linked-member.md). When a primary member shares a membership with someone linked to them, the linked member receives their own subscription record that points back at the primary's. This endpoint finds those records and **deletes them outright**. The secondary member stops being entitled under the primary's membership immediately.

Be clear about what it does and does not touch. It deletes only subscriptions held by `secondaryMemberId` that were created by sharing and whose parent subscription still belongs to `primaryMemberId` and has not yet ended. It does **not** delete anything from the primary member — the primary's own memberships are read, never modified. It does **not** touch memberships the secondary member bought in their own right; those are untouched because they carry no link back to a shared subscription. And it does **not** break the link between the two members: they remain linked, and the secondary can be granted the memberships again. To remove the relationship itself, use [Unlink secondary member from primary member](unlink-secondary-member-from-primary-member.md).

The shared subscriptions are permanently deleted, not cancelled or end-dated, so there is no record left of the shared entitlement and no way to restore the original subscriptions through the API. Re-granting means calling the apply endpoint again, which issues a **new** set of subscriptions with new identifiers — anything you have stored against the old subscription references will be stale.

One shared membership is deliberately left behind: if a subscription the secondary received has since expired on the primary's side, it no longer matches and is not deleted. Only shares derived from a currently active primary membership are removed.

Success is `204 No Content` with an empty body, and it is returned in two very different situations — when shared memberships were deleted, and when the pair had none to begin with. The response is identical either way, so a `204` is not evidence that anything changed. If you need to know, read the secondary member's memberships before and after. For the same reason the call is safely repeatable: a second call finds nothing left and returns `204` again.

The token must belong to `primaryMemberId`, or be acting as that member. Unlike most member endpoints, a linked member's own token is not accepted here — a secondary member cannot revoke their own shared access.

## Endpoint

`DELETE {base_url}/api/members/{primaryMemberId}/memberships/linked-memberships/{secondaryMemberId}`

`{base_url}` is the environment URL issued to your integration. See [Authenticating with Gladstone APIs](../../guides/authenticating-with-gladstone-apis.md).

## Path parameters

| Name | Type | Required | Description |
|------|------|----------|-------------|
| `primaryMemberId` | integer (int32) | Yes | The member who owns the shared memberships — the one whose subscriptions were copied to the secondary. Their memberships are only read, never changed. Must be `1` or greater and must exist. The access token must belong to this member, or be acting as them, or the call is rejected with `403`. |
| `secondaryMemberId` | integer (int32) | Yes | The linked member losing the shared access. Their shared subscriptions that derive from `primaryMemberId` are deleted; memberships they hold in their own right are left alone. Must be `1` or greater and must exist. Nothing checks that the two members are actually linked, so a wrong id here quietly removes nothing and still returns `204` — confirm the pairing against [List all of a member's linked members](list-all-of-a-members-linked-members.md) first. |

## Sample request

```bash title="cURL"
curl -X DELETE '{base_url}/api/members/{primaryMemberId}/memberships/linked-memberships/{secondaryMemberId}' \
  -H 'Authorization: Bearer {accessToken}' \
  -H 'X-Use-SSO: true'
```

## Errors

| Status | Meaning | When |
|--------|---------|------|
| `400` | Bad request | Either member id in the path is less than `1`. The body names the offending value — `Member Id: {id} is invalid`, or `Member Ids: {a} and {b} are invalid` when both are. |
| `404` | Not found | One or both members do not exist. The body names which — `The member with ID: {id} was not found`, or `The members with IDs: {a} and {b} were not found` when neither exists. Existence is checked before anything is deleted, so a `404` means nothing was changed. |
| `500` | Internal server error | An unexpected failure while reading the two members' memberships or deleting the shared subscriptions. Returned with an empty body. The delete is all-or-nothing, so it either applied in full or not at all; re-read the secondary member's memberships before retrying. |