# 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)

HTML version: [Get pending link requests for member](https://support.gladstonesoftware.cloud/reference/members/get-pending-link-requests-for-member)

## 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](../../guides/authenticating-with-gladstone-apis.md).

## 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

```bash title="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

```json title="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. |