Get pending link requests for member

GET /api/members/{memberId}/link-requests/pending

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

Lists the member-link invitations involving one member that are still awaiting an answer.

A link in Gladstone joins one primary member to one or more secondary members — a parent and their children, or the members of a household — so that they can book activities on each other's behalf. A member can be primary for many secondaries, but a secondary can only be linked to one primary, and only primary members can hold links.

There are two ways a link comes into being. A primary can create links outright with POST /api/members/{memberId}/links, naming the member ids to attach. Or one member can invite another with POST /api/members/{memberId}/link-requests, identifying the other person by first name, last name, date of birth and email address — that invitation is a link request, and it changes nothing until the other member agrees. A pending link request confers no booking rights whatsoever; only an established link does.

This endpoint reports both directions of that invitation flow for a single member. sent holds invitations this member raised and is waiting on. received holds invitations other members raised naming this member, which this member can accept. Everything returned is pending by definition: a request is deleted the moment the link is created or the request is cancelled, so there is no status field and nothing to filter on. A member with nothing outstanding gets 200 with two empty arrays, not a 404.

To accept an invitation from the received list, call PUT /api/members/{secondaryMemberId}/link-requests/{primaryMemberId}. Both path segments are member ids: pass the senderMemberId from the received entry as primaryMemberId, and the member you queried as secondaryMemberId. The id on each entry plays no part in acceptance — its only use is cancelling an invitation with DELETE /api/members/{memberId}/link-requests/{linkRequestId}, which works for entries in either list.

Use this endpoint for invitations that have not been answered. Once an invitation is accepted the pair are linked, and GET /api/members/{memberId}/links is the endpoint that describes the resulting relationship and its booking permissions — a link that already exists never appears here.

Access is tightly scoped: the member id in the path must match the member id in your access token exactly. Unlike the links endpoint, a linked member cannot read another member's pending requests.

Endpoint

GET {base_url}/api/members/{memberId}/link-requests/pending

{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 outstanding invitations you want. Must match the member id in your access token exactly — linked members and members with a pending request are not permitted to read it. This id is the sender for every `sent` entry and the receiver for every `received` entry.

Sample request

cURL

curl -X GET '{base_url}/api/members/{memberId}/link-requests/pending' \
  -H 'Authorization: Bearer {accessToken}' \
  -H 'X-Use-SSO: true'

Response fields

Field	Type	Description
`sent`	array of object	Invitations this member raised that the other member has not yet accepted. Always present; an empty array when there are none.
`sent[].id`	integer (int32)	The link request id. Use it only to withdraw the invitation via `DELETE /api/members/{memberId}/link-requests/{linkRequestId}`. It is not the value used to accept a request.
`sent[].firstName`	string	Given names of the member you invited, read from their member record — not the name you typed when raising the request. Use it to show who the invitation is waiting on.
`sent[].lastName`	string	Surname of the member you invited, read from their member record.
`sent[].createdOn`	string (date-time)	When the invitation was raised. Nothing expires a request automatically, so this is the only way to tell a stale invitation from a fresh one.
`sent[].senderMemberId`	integer (int32)	Always `null` in `sent` entries — only the other side of the pair is populated here. The sender is the member whose id you put in the path.
`sent[].receiverMemberId`	integer (int32)	The member id of the person you invited. Hold on to it if you later want to create the link outright with `POST /api/members/{memberId}/links`.
`sent[].email`	string	The home email address held on the invited member's record. This is their stored address, which may differ from the email you supplied when raising the request.
`received`	array of object	Invitations other members raised naming this member, which this member can accept. Always present; an empty array when there are none.
`received[].id`	integer (int32)	The link request id. Use it to decline or clear the invitation via `DELETE /api/members/{memberId}/link-requests/{linkRequestId}`; it is not used when accepting.
`received[].firstName`	string	Given names of the member who sent the invitation, read from their member record — show this so the recipient knows who is asking.
`received[].lastName`	string	Surname of the member who sent the invitation, read from their member record.
`received[].createdOn`	string (date-time)	When the invitation was raised. Requests do not expire on their own, so use this to age the list.
`received[].senderMemberId`	integer (int32)	The member id of the person who sent the invitation. This is the value you pass as `primaryMemberId` when accepting with `PUT /api/members/{secondaryMemberId}/link-requests/{primaryMemberId}`.
`received[].receiverMemberId`	integer (int32)	Always `null` in `received` entries — only the sender is populated here. The receiver is the member whose id you put in the path.
`received[].email`	string	The home email address held on the sending member's record.

Sample response

200 OK

{
  "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

Status	Meaning	When
`404`	Not found	`The member with ID: {memberId} does not exist` — raised before any request lookup, so it means the member id itself is unknown, never that the member has no pending requests. A member with none returns `200` with two empty arrays.
`500`	Internal server error	An unexpected server-side failure. Every failure other than the not-found above returns an empty `500` with no body, so there is nothing to parse — retry, then escalate.

This page as markdown · All pages · llms.txt