Billing Webhooks
The webhooks Acquired Billing sends, and when each one is sent.
Acquired Billing sends webhooks so your system can react to subscription and payment events as they happen, without polling the API.
| Webhook | webhook_type | Sent when |
|---|---|---|
| Bill Payment Webhooks | status_update | A payment is attempted against a bill. Carries subscription_id and bill_id. |
| Recovery Payment Webhooks | status_update | The Retry Engine attempts to recover a failed bill payment. Also carries recovery_id. |
| Subscription Status Webhooks | billing.subscription.status_changed | A subscription moves from one status to another, for example from active to past_due. |
All of them use the Webhook-Version 2 envelope (webhook_type, webhook_id, timestamp and webhook_body) and are signed the same way. See the Webhook Notifications guide for webhook headers and how to validate a webhook's hash.
Payments and statuses are separate webhooksA single event can send more than one webhook. For example, a declined bill payment sends a
status_updatefor the payment and, if the subscription moves topast_dueas a result, abilling.subscription.status_changedfor the subscription. Handle each webhook independently rather than relying on the order in which they arrive.
Updated 11 days ago