Failed Deliveries
What happens when webhook delivery fails and how to recover.
If Cresora cannot deliver a webhook within its retry window — 4 attempts over roughly 35 minutes, see Retry handling — the delivery is recorded EXHAUSTED and no further attempt is made.
There is no failure notification
Cresora does not tell you when a delivery fails permanently. There is no webhook.delivery_failed event — no such event exists — and no failure notification to subscribe to. You find out one of two ways: by inspecting the delivery log, or by reconciling against the Transactions API.
Build recovery on reconciliation, not on being notified. Because the retry window is ~35 minutes and nothing alerts you afterwards, a deploy or outage longer than that can lose events silently.
What to do when a delivery fails
1. Check the delivery log
Partner Portal → Developers → Webhooks — open the endpoint's delivery log. It shows every delivery attempt, response status, and the full response body your endpoint returned.
Each attempt carries one of these statuses:
| Status | Meaning |
|---|---|
SUCCEEDED | Your endpoint returned 2xx |
FAILED_TRANSIENT | Failed, and a retry is scheduled |
FAILED_PERMANENT | Rejected with a status that is never retried (see the list below) |
EXHAUSTED | The retry ladder ran out — this is the end state of a lost event |
SKIPPED_SUSPENDED | Not attempted, because the endpoint is suspended |
REJECTED_SSRF | The endpoint URL was re-validated at dispatch time and failed — for example it now resolves to a private address |
Common causes:
- Endpoint returned
5xxconsistently (server error in your handler) - Endpoint was unreachable (server down, DNS misconfigured)
- Handler took longer than 10 seconds to respond
- Handler answered
400,401,404,405,410or422— these are never retried, so the delivery failed on its first attempt
2. Fix your endpoint
Address the root cause — fix the bug, restore the server, or update the endpoint URL.
3. Replay the failed delivery
Once your endpoint is healthy, open the delivery log, find the failed event, and click Replay.
Replay is per-delivery — there is no bulk replay — and capped by default at 100 replays per endpoint per hour (429 with Retry-After beyond that). If Cresora has suspended the endpoint, resume it first: replay to a suspended endpoint is rejected.
4. Reconcile missed events
Reconciliation, not replay, is your safety net for anything older than the retry window. List the transactions created during the outage:
curl "https://api.sandbox.cresoracommerce.ai/api/v1/transactions?from=2026-05-29T00:00:00Z" \
-H "Authorization: Bearer csk_ab12cd34_xxxxxxxxxxxxxxxxxxxxxxxx"from is an inclusive ISO-8601 lower bound on created_at; add to to close the window. Results are cursor-paginated, newest first — follow the pagination cursor to walk the whole range.
On this list projection amount is an integer in minor units (cents), unlike the decimal string used on the write surface.
Process each transaction you may have missed and update your system accordingly.
When Cresora suspends an endpoint
To stop retry storms against an endpoint that is clearly down, Cresora suspends delivery when both conditions hold over a 24-hour window:
- at least 50 delivery attempts, and
- a failure rate above 90%
A suspended endpoint stops receiving events, and replay to it is rejected.
Resuming is manual. Delivery does not restart on its own when your endpoint recovers — you must resume the endpoint in the Partner Portal under Developers → Webhooks. Suspension does not send you a webhook either, so check the endpoint's state as part of your incident recovery.