# Delete link request

`DELETE /api/members/{memberId}/link-requests/{linkRequestId}`

- **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: [Delete link request](https://support.gladstonesoftware.cloud/reference/members/delete-link-request)

## Overview

Removes a single pending link request. This is how a sender withdraws a request they raised and how a recipient rejects one they were sent — the same call serves both, and there is no separate "reject" endpoint. The request is deleted outright rather than flagged as cancelled, so nothing about it survives the call: there is no soft-delete flag, no audit record you can read back, and no way to restore it. Raise a fresh request with [Send link request to another member](send-link-request-to-another-member.md) if you change your mind.

Either party to the request may delete it. The request must involve `memberId` as its sender **or** its receiver; that single condition is the whole permission model here. It is applied when the request is looked up rather than as an authorisation check, which has an important consequence: passing a `linkRequestId` that belongs to two other members returns `404`, not `403`. You cannot tell "no such request" apart from "that request is not yours" from the response. Note also that, unlike the other operations on this route, this one does not require the token's member to match `memberId`.

On success the endpoint returns `200 OK`. The operation is not idempotent — the request no longer exists, so calling again with the same `linkRequestId` returns `404`. Treat that `404` as ambiguous rather than as proof the request was never there, because a pending request can disappear for several other reasons: it is consumed when the recipient accepts it via [Accept a link request from a primary member](accept-a-link-request-from-a-primary-member.md), and pending requests between a primary and the members being linked are deleted wholesale by [Create member links](create-member-links.md). Deleting a request only removes the request. It never unlinks members who are already linked, and it never touches memberships; use [Unlink secondary member from primary member](unlink-secondary-member-from-primary-member.md) for that.

Take `linkRequestId` from the `id` of an entry returned by [Get pending link requests for member](get-pending-link-requests-for-member.md) — that is the only place the value is published.

One discrepancy is worth planning for: the response fields below describe a pending-link-requests object, but this endpoint returns `200 OK` with an **empty body**. Do not parse the response to discover what is left outstanding; call [Get pending link requests for member](get-pending-link-requests-for-member.md) afterwards instead.

## Endpoint

`DELETE {base_url}/api/members/{memberId}/link-requests/{linkRequestId}`

`{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 on whose behalf you are removing the request. This must be either the sender of the request (you are withdrawing it) or its receiver (you are rejecting it) — the request is only found when `memberId` matches one of those two. Supplying an unrelated member returns `404` rather than `403`, so a wrong value here looks identical to a missing request. |
| `linkRequestId` | integer (int32) | Yes | The request to delete. Take this from the `id` of a `sent` or `received` entry returned by [Get pending link requests for member](get-pending-link-requests-for-member.md); it identifies the request itself, not either of the members involved. Must be `1` or greater — anything lower is rejected with `400` before the request is looked up. |

## Sample request

```bash title="cURL"
curl -X DELETE '{base_url}/api/members/{memberId}/link-requests/{linkRequestId}' \
  -H 'Authorization: Bearer {accessToken}' \
  -H 'X-Use-SSO: true'
```

## Response fields

| Field | Type | Description |
|-------|------|-------------|
| `sent` | array of object | The requests raised **by** the member — the ones they can withdraw. Not populated by this endpoint, which returns an empty `200` body; the field is filled in only by [Get pending link requests for member](get-pending-link-requests-for-member.md). Defaults to an empty array rather than `null` when the member has raised none. |
| `sent[].id` | integer (int32) | Identifies the link request itself. This is the value to pass as `linkRequestId` when withdrawing it. |
| `sent[].firstName` | string | The given name of the member the request was sent **to**, copied from that member's profile — not the name of the member who sent it. |
| `sent[].lastName` | string | The family name of the member the request was sent **to**, copied from that member's profile. |
| `sent[].createdOn` | string (date-time) | When the request was raised; use it to age out stale invitations. May be absent. |
| `sent[].senderMemberId` | integer (int32) | The member who raised the request. For entries in `sent` this is the member named in the path. If the request is accepted, this member becomes the primary of the linked pair. May be absent. |
| `sent[].receiverMemberId` | integer (int32) | The member the request was addressed to, and the only member besides the sender who can act on it. If the request is accepted, this member becomes the secondary of the linked pair. May be absent. |
| `sent[].email` | string | The home email address held on the profile of the member the request was sent to. Use it to confirm you invited the right person before withdrawing the request. |
| `received` | array of object | The requests addressed **to** the member — the ones they can accept or reject. Not populated by this endpoint, which returns an empty `200` body; the field is filled in only by [Get pending link requests for member](get-pending-link-requests-for-member.md). Defaults to an empty array rather than `null` when the member has received none. |
| `received[].id` | integer (int32) | Identifies the link request itself. This is the value to pass as `linkRequestId` when rejecting it. |
| `received[].firstName` | string | The given name of the member who **sent** the request, copied from that member's profile — not the name of the member receiving it. |
| `received[].lastName` | string | The family name of the member who **sent** the request, copied from that member's profile. |
| `received[].createdOn` | string (date-time) | When the request was raised by the sender. May be absent. |
| `received[].senderMemberId` | integer (int32) | The member who raised the request. Pass this as `primaryMemberId` if you accept it with [Accept a link request from a primary member](accept-a-link-request-from-a-primary-member.md). May be absent. |
| `received[].receiverMemberId` | integer (int32) | The member the request was addressed to. For entries in `received` this is the member named in the path. May be absent. |
| `received[].email` | string | The home email address held on the profile of the member who sent the request, so the recipient can identify who is asking to link to them. |

## 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 |
|--------|---------|------|
| `400` | Bad request | `linkRequestId` is `0` or negative. The message reads `LinkRequestId must be a valid, positive number`. This is checked before the request is looked up, so nothing is deleted. |
| `404` | Not found | No pending link request with this id involves `memberId` as either its sender or its receiver. The message reads `The link request with the ID: {linkRequestId} does not exist.` The same response covers all of: the id never existed, you already deleted it, the recipient has since accepted it, it was cleared out by [Create member links](create-member-links.md), and the request exists but belongs to two other members. |
| `500` | Internal server error | An unexpected server-side failure while finding or deleting the request. The delete is all or nothing, so a `500` should leave the request in place — but re-read the member's pending requests rather than assuming it. |