Send link request to another member

POST /api/members/{memberId}/link-requests

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

Invites another existing member to be linked to this one, so the two accounts can share memberships and book for each other. The invitation is pending until the other member accepts it with Accept a link request from a primary member; nothing is linked by this call alone.

You identify the other member by their personal details, not by their member id. All four fields must match a member record: first name and last name compared case-insensitively, email compared exactly, and date of birth matched to the day. If no member matches, the request fails with 404 — which in practice means "these details do not identify anyone", not "that person has no account".

The rules the sender and receiver must satisfy are strict, and each has its own status code:

• The sender must not already be a secondary member of someone else's link (409).
• The receiver must not be a primary member, and must not already be linked to anyone (409).
• The receiver must be at or above the tenant's age of consent (400). Juniors are linked by other means, not by invitation.
• You cannot invite yourself, invite someone already linked to you, or send a second invitation to the same person while the first is pending (400).
• The sender's existing links and pending requests together are capped by the tenant's maximum-linked-members setting. Note the check is existing + pending >= maximum − 1, so the effective ceiling is one below the configured number.

On success a message is published internally, which is what triggers the notification to the invited member.

Linked members are permitted — a token issued for a member linked to {memberId} may call this endpoint.

Endpoint

POST {base_url}/api/members/{memberId}/link-requests

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

Path parameters

Request body

All four fields identify the member being invited, and all four are used in the lookup — omitting any of them will fail to match.

Sample request

curl -X POST '{base_url}/api/members/{memberId}/link-requests' \
  -H 'Authorization: Bearer {accessToken}' \
  -H 'X-Use-SSO: true' \
  -H 'Content-Type: application/json' \
  -d '{
  "firstName": "string",
  "lastName": "string",
  "dateOfBirth": "2026-08-14T19:00:00Z",
  "email": "member@example.com"
}'

Response fields

This action returns the single link request it created — a flat object with id, firstName, lastName, createdOn, senderMemberId, receiverMemberId and email — not the sent/received envelope shown below. That envelope is the shape returned by Get pending link requests for member; the two share a response type in the schema. Build against the flat object, and use the pending-requests endpoint if you need both directions.

Sample response

{
  "sent": [
    {
      "id": 12345,
      "firstName": "string",
      "lastName": "string",
      "createdOn": "2026-08-14T19:00:00Z",
      "senderMemberId": 12345,
      "receiverMemberId": 12345,
      "email": "member@example.com"
    }
  ],
  "received": [
    {
      "id": 12345,
      "firstName": "string",
      "lastName": "string",
      "createdOn": "2026-08-14T19:00:00Z",
      "senderMemberId": 12345,
      "receiverMemberId": 12345,
      "email": "member@example.com"
    }
  ]
}

Errors

This page as markdown · All pages · llms.txt