> ## Documentation Index
> Fetch the complete documentation index at: https://docs.qa.esectra.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Webhook delivery inspection and resend

> See exactly what a webhook delivery sent, and send it again.

Every delivery keeps the event it carried. `WEBHOOKS_MANAGE` - held by compliance officers and admins in Control, and by every tenant API key - reads it back and can send it again.

## Inspect a delivery

```bash theme={null}
curl "$ESECTRA_BASE_URL/v1/webhooks/deliveries/$DELIVERY_ID" \
  -H "Authorization: Bearer $ESECTRA_API_KEY"
```

The answer is the delivery record - `event_id`, `event_type`, `status`, `attempts`, `last_response_status`, `last_error`, `next_attempt_at`, `created_at`, `updated_at` - with:

* `payload`: the JSON body that was sent, parsed, for reading;
* `payload_json`: the exact bytes that were sent, as a string. This is what the signature covered and what a resend sends again;
* `endpoint`: `endpoint_id`, `url` and `active` for the destination, when it is still configured;
* `signature_header` and `event_id_header`: the header names a receiver checks.

The signing secret is never returned, and neither is a signature. In Control, the Webhooks page opens a delivery in a drawer with the payload formatted; *Copy payload* copies `payload_json` byte for byte.

## Send it again

```bash theme={null}
curl -X POST "$ESECTRA_BASE_URL/v1/webhooks/deliveries/$DELIVERY_ID/resend" \
  -H "Authorization: Bearer $ESECTRA_API_KEY" \
  -H "Idempotency-Key: $(uuidgen)"
```

A resend is a **new delivery record** that points at the original (`resent_from_delivery_id`) and names who asked (`requested_by`). The receiver gets the same `Esectra-Event-Id` and the same bytes under a signature made now, so its replay window sees a fresh request and its deduplication sees a repeat. The original delivery's record is not changed; the new one has its own attempts and is retried by the worker like any other.

`Idempotency-Key` is required. Replaying a key answers `200` with the delivery the first call made, so a double click or a retried request produces one delivery. A key reused for a different delivery answers `409 IDEMPOTENCY_KEY_REUSED`; one held by a request still running `409 RESEND_IN_PROGRESS`.

A resend to a disabled endpoint is refused with `409 WEBHOOK_ENDPOINT_DISABLED` - disabling means deliveries stop, manual ones included - and to a removed one with `409 WEBHOOK_ENDPOINT_MISSING`. Another tenant's delivery is `404 WEBHOOK_DELIVERY_NOT_FOUND`.

Every resend is an audit event, `WEBHOOK_RESEND_REQUESTED`, under the person or key that asked, naming the original and the new delivery.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.