- Push, not poll: your system learns about a change within seconds instead of on the next sync
- Signed and retried: every delivery on Flexprice Cloud is signed with HMAC-SHA256 and retried for days on failure
- Typed payloads: each event’s JSON is documented in the API reference and modelled in every SDK
How webhook delivery works
1
Register an endpoint
Add an HTTPS URL in the dashboard under Developers > Webhooks and pick the events it should receive. Each endpoint gets its own signing secret. See Set up an endpoint.
2
Flexprice sends a POST
The body is JSON with an
event_type and the object that changed:3
Your handler verifies, acknowledges, and processes
Check the signature on the raw body, return
2xx within 5 seconds, and do the work on a queue. See Signature verification.4
Failures are retried
A non-
2xx response or a timeout is retried on a backoff schedule, so handlers must tolerate duplicates and reordering. See Retries and ordering.Which events Flexprice sends
Sixty-nine event types cover customers, subscriptions, invoices, payments, refunds, credit notes, wallets, features, entitlements, commitments and billing terms, checkout sessions, and usage ingestion. The event catalog lists every one with a link to its payload schema. The ones most integrations start with:Webhook delivery on Cloud and self-hosted
Flexprice Cloud always uses Svix. A self-hosted instance uses native delivery unless Svix is turned on in configuration.
Webhook handler best practices
- Verify every signature before reading the body.
- Respond fast and process later. Anything over 5 seconds is a failure.
- Dedupe on
svix-id. Delivery is at-least-once. - Treat payloads as snapshots. Read the status from the body and compare
updated_atrather than assuming order. - Return
200for events you do not handle so they are not retried. - Register separate endpoints per environment with separate secrets.
- Subscribe to
event.rejectedso dropped usage is never silent.

