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.

Event stored · 202
test
order.completed
evt_8e12c · signed · idempotency order-123
Stored
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 state
POSThttps://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.