# Apply shared memberships to linked member

`POST /api/members/{primaryMemberId}/memberships/link-memberships-to-member/{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: [Apply shared memberships to linked member](https://support.gladstonesoftware.cloud/reference/members/apply-shared-memberships-to-linked-member)

## Overview

Issues the secondary member their own copy of each of the primary member's shareable memberships. Only memberships whose type is flagged to apply to links are copied; anything the primary holds that is not flagged that way is left alone. The secondary member ends up with new subscriptions of their own, not a view onto the primary's — so this genuinely grants entitlement rather than merely recording a relationship.

**This call is not idempotent, and calling it twice is the mistake to avoid.** Nothing checks whether the secondary member already holds the memberships being applied, and a fresh block of subscription ids is allocated on every call, so a second call issues a second set of subscriptions. There is no "sync" or "reconcile" behaviour to fall back on. If a call fails and you are unsure whether it took effect, read the secondary member's memberships before retrying, and use [Remove shared membership access between linked members](remove-shared-membership-access-between-linked-members.md) to undo an application.

Run it after the link exists, not before. The primary member must already be flagged as a primary with no parent link of their own — that is what [Create member links](create-member-links.md) sets up — and until then this endpoint returns `400`. On success it returns `200 OK` with an empty body.

The two membership checks are asymmetric, and the gap matters. The primary is verified to be a primary; the secondary is only verified **not** to be a primary. The endpoint does not check that the secondary is actually linked to *this* primary, so a mistyped `secondaryMemberId` that happens to name an unlinked or differently-linked member will be accepted and given the primary's memberships. Validate the pairing yourself against [List all of a member's linked members](list-all-of-a-members-linked-members.md) before calling.

If the primary member holds no memberships flagged to apply to links, there is nothing to copy: the call still returns `200` and the secondary member gains nothing. A success response is therefore not evidence that any membership was granted.

You rarely need to call this directly during sign-up. [Create a new linked member for a primary member](create-a-new-linked-member-for-a-primary-member.md) and [Accept a link request from a primary member](accept-a-link-request-from-a-primary-member.md) both perform this step for you as part of their sequence.

## Endpoint

`POST {base_url}/api/members/{primaryMemberId}/memberships/link-memberships-to-member/{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 whose memberships are being shared. This member must already be flagged as a primary **and** have no parent link of their own; if either is untrue the call fails with `400` and the message `The primary member is not a primary one.` This member's site is used when allocating the ids for the new subscriptions. The token must belong to this member, or to a linked member permitted to act for them, or the call fails with `403`. |
| `secondaryMemberId` | integer (int32) | Yes | The member receiving copies of those memberships. This member must exist and must not themselves be flagged as a primary — a primary of another group is rejected with `400`. Note that the endpoint does **not** verify that this member is linked to `primaryMemberId`, so an incorrect id here is silently accepted and granted the memberships. Passing the same id as `primaryMemberId` is rejected by that same check, since a primary member fails it. |

## Sample request

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

## Errors

| Status | Meaning | When |
|--------|---------|------|
| `400` | Bad request | `primaryMemberId` is not flagged as a primary member, or is itself linked to another member as a secondary. The message reads `The primary member is not a primary one.` Link the pair with [Create member links](create-member-links.md) first. |
| `400` | Bad request | `secondaryMemberId` is itself flagged as a primary member and so cannot receive another member's memberships. The message reads `The secondary member can not be a primary one.` Unlink their group first. |
| `403` | Forbidden | The token belongs neither to `primaryMemberId` nor to a member linked to them who is permitted to act on the primary's behalf. A member cannot share another member's memberships. |
| `404` | Not found | Neither member could be loaded — the message reads `The primary and secondary members were not found.` Where only one is missing, the message names it: `The primary member was not found.` or `The secondary member was not found.` |
| `422` | Unprocessable entity | The new subscriptions could not be written. A rejected membership operation is returned as `Unable to process this request: {reason}`; a failure saving them, typically caused by missing or inconsistent membership-type configuration, is returned as `Unable to process this request due to a configuration issue`. Some subscriptions may already have been created when this occurs — check the secondary member's memberships before retrying. |
| `500` | Internal server error | An unexpected failure while reading the primary member's memberships, resolving membership types, or allocating subscription ids. |