Failed deliveries retry within a finite policy.
A stored event and an enabled endpoint go in. Up to 8 delivery attempts come out, from seconds to hours apart, each with status, duration, and timestamp.
test
order.completed
evt_8e12c · signed · idempotency order-123
https://hooks.example.com/orders
Delivery attempts
Persisted before any endpoint is called. Your request already returned HTTP 202.
What it does
Real product states, not a promise.
A stored event and an enabled endpoint go in. Up to 8 delivery attempts come out, from seconds to hours apart, each with status, duration, and timestamp.
- Backoff from 5 seconds to 10 hours
- Up to 8 attempts per delivery
- Failed deliveries stay inspectable and replayable
- Repeated failures surface as an Issue
Input
A stored event and an enabled endpoint
Output
Recorded delivery attempts
Where it fits
Where it fits
01
Receivers with maintenance windows
02
Rate-limited destinations
03
Recovering after an outage
API example
One request.
Delivery retry policy. The full request and response contract is in Flowyn Docs.
AcceptedClaimedAttemptedTerminal state# Delivery retry policy
# Request and response: /docs/connect/eventsFrequently asked questions
Where is the exact request contract for Webhook Retries?
In Flowyn Docs and the OpenAPI document at https://api.flowyn.dev/openapi/v1.yaml. This page shows the request; the docs page lists every field, status value, error, and limit.
Is delivery exactly once?
No. Delivery is at-least-once. Receivers should deduplicate on the webhook-id header, which is the event id and stays the same across retries.
What does replay do?
Replay sends the same event again as a new delivery. The original attempts remain in history.
Build with Webhook Retries.
Create a workspace, make your first call in the test environment, and inspect every attempt.