Clear Scheduled Pause
Authentication
Bearer authentication of the form Bearer <token>, where token is your auth token.
Path parameters
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.