This endpoint also has a customer-side flow with session-token auth: see Cancel Subscription (Customer).
Cancellation Behavior
- pending: Directly canceled, status becomes
canceled— it never passes throughcanceling - pending plan-change subscription: also becomes
canceleddirectly, but the PSP cancellation for that scheduled subscription is dispatched right away, so it neither activates nor charges at the planned switch time. The original subscription is left untouched: it stayscancelingand does not return toactive - Already ended while canceling (idempotent): if a
pendingorder reaches a terminal status after it was read but before the cancellation is written — for example two plan-change candidates were created concurrently for the same subscription and the PSP closed the one that yielded, pushing the close notification back first, or a concurrent cancellation landed first — the request converges as canceled: any discount reservation still held is released (an already released one is not released twice), and it returns 200 with the current terminal status (e.g.closed). No cancellation reason is stored in this case - active: PSP cancellation is triggered (takes effect at billing period end). Local status becomes
canceling, then updated tocanceledvia Webhook when the period ends - past_due: PSP cancellation is dispatched immediately, not deferred to period end. Local status becomes
canceling, then updated tocanceledvia Webhook once the PSP confirms. No “cancellation scheduled, access until X” email is sent on this path, because the billing period has already lapsed
Request Body
Example Request
Success Response (200) — Active Subscription
Success Response (200) — Pending Subscription
Response Fields
Errors
Retry policy: Never retry 4xx — fix the request and resubmit. Retry 5xx with exponential backoff (start 5s, max 3 attempts).