Set Cancel At Period End
Set whether subscription should cancel at period end.
Optionally accepts a JSON body with cancellation_details (comment, feedback, reason) to record why the subscription is being scheduled for cancellation.
Works for both User and API Key authentication. Account access is automatically validated via endpoint dependency.
Authentication
Bearer authentication of the form Bearer <token>, where token is your auth token.
Path parameters
Query parameters
Request
Optional details about why the subscription is being cancelled (comment, feedback, reason)
Response
The possible states of a subscription.
Most are self-explanatory: it starts INCOMPLETE (created, not yet paid for), or TRIALING / SCHEDULED, becomes ACTIVE once paid, and can end up PAUSED, PAST_DUE (a payment failed), or CANCELLED.
ACTIVE_UNSETTLED is the unusual one, added for slow bank rails like SEPA where the money does not arrive until days later. It means: “we already let the customer in at checkout, but their payment has not actually settled yet.” A subscription is created straight into this state — nothing ever moves INTO it from another state. It has exactly two ways out: it becomes ACTIVE if the payment settles, or CANCELLED if the payment fails, times out, or is later reversed (a chargeback).
Refund options when cancelling a subscription.
- NONE: Cancel with no refund (current behavior)
- FULL: Refund full current period amount
- PRORATED: Refund unused portion of current period
- CANCEL_UNPAID: Use dunning_end_behavior for unpaid invoices
Details about why a subscription was cancelled.
All fields are optional — callers can provide any combination. Stored as JSONB on the subscription entity.
ID of the subscription this was split from (cross-interval plan change).
IDs of subscriptions created from this one (cross-interval plan change).
Custom field values. Only included when expand=custom_fields is specified.