Redeliver
Replay a finished delivery: reset it to PENDING and re-fire the signed POST.
404 if the delivery isn’t visible to the caller; 409 if a delivery for the
request is still in flight (a replay must not stack on it). The delivery is
re-validated (SSRF) and re-signed at send time, and the receiver dedupes on
X-Hedra-Webhook-Id, so a replay is safe.
The webhook id is stable across the original and every replay, because it
identifies the event. Every attempt of a replayed cycle therefore also carries
X-Hedra-Webhook-Redelivery: true — without it a receiver doing exactly what
our guidance says (dedupe on the id) would silently discard the replay, which is
the one case where the duplicate is the point.
Authorizations
Primary scheme: Authorization: Key <key_id>:<secret>.
Path Parameters
Response
Successful Response
Where a delivery stands: queued, in flight, or its terminal outcome.
PENDING, DELIVERING, DELIVERED, FAILED Which URL resolution created this delivery.
per_job, default The terminal events an outbound webhook announces.
One delivery carries exactly one of these, chosen from the job's final status when the delivery fires.
job.completed, job.failed Why the most recent delivery attempt failed, in the same error envelope GET /jobs/{job_id} returns for a failed job: a stable code from the shared error vocabulary, a fixed operator-facing message, and retryable. Null while no attempt has failed. Destination URLs, addresses, headers, credentials, response bodies, and internal exception text are never included — those stay in Hedra's own logs. retryable describes the condition, not what Hedra did: every non-2xx response is retried on the published ladder, so it answers whether replaying this delivery is likely to help. Deliveries that failed before this field became structured report UNKNOWN.