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)

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 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, and pending requests between a primary and the members being linked are deleted wholesale by Create member links. 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 for that.

Take linkRequestId from the id of an entry returned by Get pending link requests for member — 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 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.

Path parameters

Sample request

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

Response fields

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