Send an event again, keep the history.
A stored event goes in. A new delivery comes out, freshly signed, while the original attempts stay in history.
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 goes in. A new delivery comes out, freshly signed, while the original attempts stay in history.
- New delivery, original attempts untouched
- Same payload, freshly signed
- Available from the API and the dashboard
- Useful after fixing a receiver
Input
A stored event
Output
A new delivery of the same payload
Where it fits
Where it fits
01
Receiver bug fixed, resend
02
Reprocessing after a migration
03
Debugging a consumer
API example
One durable request.
POST /v1/events/{id}/replay. Use an idempotency key on create calls. The full request and response contract is in Flowyn Docs.
AcceptedClaimedAttemptedTerminal statePOSThttps://api.flowyn.dev/v1/events/{id}/replay202
curl -X POST https://api.flowyn.dev/v1/events/{id}/replay \
-H "Authorization: Bearer flw_test_••••" \
-H "Content-Type: application/json" \
-H "Idempotency-Key: replay-order-123"Frequently asked questions
Where is the exact request contract for Event Replay?
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 the operation durable?
Yes. The operation is stored before any work happens and remains a resource with state, attempts, and error context, not an ephemeral request log.
Do failures stay inspectable?
Yes. Every attempt is recorded. Repeated failures with the same fingerprint are also grouped into an Issue.
Build with Event Replay.
Create a workspace, make your first call in the test environment, and inspect every attempt.
