A cancelling member took the offer the cancellation screen made.
When this fires
A member on the cancellation screen accepted the one offer the project makes for their rail: a pause for one billing cycle where the rail can hold the charge (Stripe, PayPal), a discount on the renewals where the rail can carry a coupon (Stripe), or a coupon to come back with everywhere else. A pause holds the charge at the gateway and pauses access, and the hourly sweep lets the member back in when resumes_at passes; a discount is minted once at the gateway and applied to the subscription; a return coupon is handed to the member on the screen and in a chat message, and the cancellation goes on. The offer is re-derived when the member accepts, so a stale screen cannot claim an offer the project no longer makes.
Caveats
- A pause taken here keeps the subscription: it reads as paused until resumes_at, and no subscription.cancelled follows. A return coupon does not: the cancellation goes on and subscription.cancelled fires as usual.
- A member sees one offer per cancellation. Declining it fires nothing; the shown offer is still counted on the cancellation record.
Related events
- subscription.cancellation_feedback: the reason recorded just before.
- subscription.paused / subscription.unpaused: the pause's two ends.
- coupon.redeemed: a return coupon used at checkout.
Headers
t=<unix seconds>,v1=<hex>: the HMAC-SHA256 of "<t>.<raw body>" under the endpoint's secret. Verify it before acting, and refuse a t more than 300 seconds from now. During a secret rotation a v0= signature under the previous secret may precede v1=.
The event's ULID, bare. The envelope's id is the same ULID prefixed evt_, so strip the prefix before comparing. Deduplicate on it: a retry carries the same id.
The event name, the same as the envelope's type.
Always application/json.
Always Subscriby-Webhooks/1.0.
Payload
Response
Your endpoint acknowledged the delivery. Any 2xx status within 30 seconds marks it delivered; the response body is ignored.
Changes
Webhooks have no change history: a webhook is keyed by its event name rather than a path and method, so no recorded change can name it.