Requests & replay

The request log is the raw truth of what hit your front door: every inbound request — including ones for unknown paths and paused endpoints — captured with its headers, body, source and outcome, and kept replayable for the retention window (30 days by default). Nothing here depends on your configuration having been right at the time: the log records what arrived, so you can always fix the config and run it again.

Two kinds of replay

Emithook has two replay verbs, and the difference matters:

	Replay a request	Replay an event
Operation	POST /v1/requests/{id}/replay	POST /v1/events/{id}/replay
What re-runs	The whole pipeline from the top: resolve → verify → route → deliver	Delivery only — the event re-fans-out to its destinations
Use it when	The processing was wrong at the time: endpoint was missing or paused, secret was wrong (quarantined), no route matched	The delivery failed or the receiver lost it: your server was down, a bug ate the payload
Marking	Idempotent on the request id	Flagged webhook-replayed: true so receivers can distinguish re-deliveries

Rule of thumb: fix-then-replay the request when the event never made it through the pipeline; replay the event when it went through fine and you just need it delivered again.

Inspect the log

# Everything the front door received for one endpoint, newest first
curl -s "https://api.emithook.com/v1/requests?endpoint=<endpoint-id>" \
  -H "Authorization: Bearer $EMITHOOK_API_KEY"

# Only the ones that hit an unknown path (typo'd provider config, probes…)
curl -s "https://api.emithook.com/v1/requests?outcome=dropped_unknown" \
  -H "Authorization: Bearer $EMITHOOK_API_KEY"

# One request in full — headers + body, claim-check resolved
curl -s "https://api.emithook.com/v1/requests/<request-id>" \
  -H "Authorization: Bearer $EMITHOOK_API_KEY"

Outcomes are accepted (console: stored), parked_inactive (held — endpoint paused), and dropped_unknown (rejected — no endpoint matched). Time-box any query with since / until.

In the console this is the Incoming requests screen (and the Recent requests card on each endpoint's Overview) — click any row to inspect source, headers and body, or replay it from the peek.

Replay a request

Re-enqueues the captured request onto the ingest buffer; the router re-processes it exactly as if it had just arrived — including verification and routing against your current config:

curl -s -X POST "https://api.emithook.com/v1/requests/<request-id>/replay" \
  -H "Authorization: Bearer $EMITHOOK_API_KEY"
# → 202 Replay queued

Typical flows: create the missing endpoint → replay the dropped_unknown requests; fix the signing secret → replay what was quarantined; unpause and replay what was held.

Replay an event

Re-delivers a stored event to its destinations. The delivery carries webhook-replayed: true, so receivers that care can dedupe on the event id:

curl -s -X POST "https://api.emithook.com/v1/events/<event-id>/replay" \
  -H "Authorization: Bearer $EMITHOOK_API_KEY"
# → 202 Replay queued

# Find candidates: everything that failed in the last day
curl -s "https://api.emithook.com/v1/events?status=failed&since=$(date -u -v-1d +%Y-%m-%dT%H:%M:%SZ)" \
  -H "Authorization: Bearer $EMITHOOK_API_KEY"

Dead-letter redrive

Events that exhausted every retry sit in the dead-letter queue — nothing is discarded. Once the receiving side is healthy again, redrive them in bulk:

curl -s -X POST "https://api.emithook.com/v1/dlq/redrive" \
  -H "Authorization: Bearer $EMITHOOK_API_KEY"

The console's dashboard surfaces DLQ backlogs under Needs attention, with redrive one click away.

Retention

Requests and events are replayable for the retention window — 30 days by default (deployment-configurable). The hourly archive job writes everything to object storage before the log prunes, so older events remain restorable from the archive even after they leave the live log.

Where to go next

• How requests are processed — the pipeline each replayed request re-enters.
• API reference — auth, pagination and conventions for the endpoints used above.