Cancel a membership for the paying member

POST /api/members/{memberId}/memberships/{membershipRef}/cancel

Success: 200 OK

Products: Operator (FOH), Consumer (CONSUMER) (any one of these products, not all)
Features: Online Joining (ONLINEJOIN), Front of House Generic Access (FOHGENERIC) (any one of these features, not all)

Overview

Cancels a membership on the instruction of the member who pays for it — the action behind a "cancel my membership" button in a self-service account area. Call Get member memberships and payment information first: each membership there carries a cancellation object saying whether this call will succeed, what it will do, and which dates the member may choose from. Show the member that outcome and get their confirmation before you call this endpoint, because a cancellation cannot be undone through the API.

The eligibility rules are checked again when you call, using the same rules as the memberships call, so a request built from an out-of-date screen is refused rather than honoured. There are two outcomes:

Inside the cooling-off period (reasonID 7), the membership ends straight away. Its end date is set to yesterday in the operator's local time — or to its start date, if it was bought to start in the future — and it will not renew. Send no body.
Outside the cooling-off period, on an auto-renewing membership (reasonID 8), the membership stops renewing and stays active until the effective date. Its current end date is not changed. Send one of the offered cancellationDates as effectiveDate, or send no body to take the earliest.

A membership that covers linked members (applyToLinks is true) is cancelled for everyone it covers.

After a successful cancellation the platform sends the member a confirmation email and sends the operator's staff an internal notification, unless the operator has switched either email off. The internal notification goes to the addresses in the operator's Self-Serve Cancellation Internal Recipients setting; when that is blank, no notification is sent.

This endpoint does not refund anything. A member who cancels inside the cooling-off period may be owed money, and the operator's staff handle that from the internal notification. Do not tell the member a refund has been made.

The cooling-off period is the operator's configured cooling-off period, counted in days from the date the membership was bought, not the date it starts. An operator that has not configured one gets 14 days.

Endpoint

POST {base_url}/api/members/{memberId}/memberships/{membershipRef}/cancel

{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 asking to cancel. Must be greater than `0` — `0` and negative values are rejected with `400`. This must be the member who pays for the membership: if the membership is allocated to this member but paid for by someone else, such as a parent paying for a child, the request is refused with `409` and `reasonID` `2`. Compare it with `paidByMember.id` from the memberships call.
`membershipRef`	integer (int32)	Yes	The membership to cancel — the `membershipRef` of an entry returned by Get member memberships and payment information for the same `memberId`. Not the membership type `id`. If the member holds or pays for no membership with this reference, the request fails with `404`.

Request body

The body is optional. Omit it entirely, or send {}, to take the earliest offered date.

Field	Type	Required	Description
`effectiveDate`	string (date)	No	The date the cancellation takes effect, as a calendar date (`YYYY-MM-DD`): the last day the member keeps their membership. Only for a membership whose `cancellation.reasonID` is `8`, and it must be one of the dates in that membership's `cancellation.cancellationDates` — any other date is rejected with `400`. The list is worked out again when you call, so a date offered yesterday may no longer be accepted today if it has dropped off the front of the list. Sending it at all for a membership inside its cooling-off period (`reasonID` `7`) is rejected with `400`, because that cancellation takes effect immediately. When omitted, the earliest offered date is used.

Sample request

cURL

curl -X POST '{base_url}/api/members/{memberId}/memberships/{membershipRef}/cancel' \
  -H 'Authorization: Bearer {accessToken}' \
  -H 'X-Use-SSO: true' \
  -H 'Content-Type: application/json' \
  -d '{
  "effectiveDate": "2026-11-16"
}'

Response fields

Field	Type	Description
`membershipRef`	integer (int32)	The membership that was cancelled, as sent in the path.
`reason`	string	The outcome the cancellation was carried out under, in English — the same text as `cancellation.reason` on the memberships call. Not translated: use `reasonID` to choose your own copy and treat this as a fallback.
`reasonID`	integer (int32)	`7` when the membership was ended immediately inside its cooling-off period, `8` when it was set to stop renewing on `effectiveDate`. If this differs from what your screen showed, the member's situation changed between the two calls — for example, the cooling-off period ended.
`effectiveDate`	string (date)	For `reasonID` `8`, the last day the member keeps the membership, as a calendar date (`YYYY-MM-DD`). `null` for `reasonID` `7`, because the membership has already ended.

Sample response

200 OK

{
  "membershipRef": 3014,
  "reason": "This membership will stop renewing and remain active until its cancellation takes effect",
  "reasonID": 8,
  "effectiveDate": "2026-11-16"
}

409 Conflict

{
  "allowed": false,
  "reason": "Only the member who pays for this membership can cancel it",
  "reasonID": 2,
  "cancellationDates": []
}

Errors

Status	Meaning	When
`400`	Bad request	`memberId` is `0` or negative. The body is `{memberId} is an invalid member ID`.
`400`	Bad request	`effectiveDate` was sent for a membership that is cancelled immediately — `Membership {membershipRef} cancels immediately, so it cannot be asked to take effect on a later date.`
`400`	Bad request	`effectiveDate` is not one of the membership's current `cancellationDates` — `{dd/MM/yyyy} is not one of the dates membership {membershipRef} can be cancelled on.`
`400`	Bad request	`effectiveDate` is not a valid date. The body is a validation problem document (`application/problem+json`) with an `errors` map keyed by field name.
`404`	Not found	The member holds or pays for no membership with this reference — `Membership {membershipRef} was not found for member {memberId}.` Expired memberships are still found, and refused with `409` instead.
`409`	Conflict	The member may not cancel this membership. The body is the same `cancellation` object the memberships call returns, with `allowed` `false`; branch on `reasonID` (`2` to `6`, listed below). Nothing is changed.
`501`	Not implemented	The member may cancel, but the membership's own terms do not produce a date for the cancellation to take effect on — `Membership {membershipRef} can be cancelled but its contract terms do not yield a date for it to take effect.` This is the same situation as an empty `cancellationDates` list on a `reasonID` `8` membership. Nothing is changed; the member needs to contact the operator.
`501`	Not implemented	The membership is in a cancellable state this endpoint cannot carry out — `Cancelling membership {membershipRef} is allowed but the outcome is not one this endpoint can action.` Nothing is changed.
`500`	Internal server error	Any other unexpected failure. No detail is returned.

The reasonID values a 409 can carry:

`reasonID`	`reason`	When
`2`	`Only the member who pays for this membership can cancel it`	`memberId` is not the paying member — typically a linked family member whose membership someone else pays for.
`3`	`This membership can only be cancelled during the cooling-off period`	A membership that does not auto-renew, past its cooling-off period. It will simply end on its expiry date.
`4`	`This membership cannot be cancelled because all of its uses have been taken`	A usage membership (a bundle of visits) inside its cooling-off period with no uses left.
`5`	`This membership has already been cancelled`	The membership already has a `renewalStopDate`, whether set by the member or by the operator's staff.
`6`	`This membership has already expired`	Nothing is left to cancel.

reasonID 1 (Self-service cancellations are not enabled) is also defined. The numbering will only ever be added to, never changed, so it is safe to switch on.

Notes

Each cancellation date is the last day the member keeps access, so it falls the day before a renewal that will then not happen. For a monthly membership, up to twelve dates are offered, a year ahead; for a yearly one, one.
Dates are never earlier than the membership's minimum term. When earliestEndDate is set, no date before it is offered. When it is not set, the membership is treated as having no minimum term.
The notice period is the one the member agreed to when they joined, where one was recorded; otherwise the membership type's current notice period is used. With no notice period at all, the earliest date offered is the day before the next payment.
Dates are aligned to the day of the month the membership originally started. For a membership collected by Direct Debit on a fixed collection day, the dates offered may sit a few days away from the actual collection date.
The cancellation is recorded in the member's event log as a cancellation by the member, so the operator can tell it apart from one made by staff.

This page as markdown · All pages · llms.txt