# HTTP headers

Every header Webhooker adds to a delivery, every header it reads on ingest, and what happens to the sender's own headers.

Source: https://docs.webhooker.eu/reference/http-headers/

## Headers we send

Added to each delivery, depending on the gateway's authentication:

| Header | When | Value |
| --- | --- | --- |
| `Content-Type` | The inbound event had one | Copied from the event. |
| `X-Webhooker-Signature` | HMAC signing | `v1=<hex>` — HMAC-SHA256 over `{timestamp}.{body}`. |
| `X-Webhooker-Timestamp` | HMAC signing | Unix seconds at signing time. |
| `X-Webhooker-Event-Id` | HMAC signing | The event id. Stable across attempts and replays. |
| your header name | API key auth | The configured key, verbatim. |
| `Authorization` | Basic auth | `Basic base64("user:password")`. |

Plus any **fixed headers** configured on the destination, and anything your
transformation sets. Authentication headers are applied last, so they cannot be
overwritten by a transformation.

Verification code for the signature is in
[verify our signature](/deliver/verify-signatures/).

## Headers we read

On ingest, depending on the source's verification method:

| Header | Read for |
| --- | --- |
| `Stripe-Signature` | Stripe verification. |
| `X-Hub-Signature-256` | GitHub verification. |
| `X-Shopify-Hmac-Sha256` | Shopify verification. |
| your signature header | HMAC verification. |
| your timestamp header | HMAC verification with replay protection. |
| `Authorization` | Basic auth verification. |
| your header name | API key verification. |
| `Content-Type` | Recorded and forwarded. |

Every other inbound header is stored as-is and available to filters as
`headers.<lowercase-name>`.

## Headers we forward

The sender's own headers are **not** forwarded by default — a delivery carries
the content type, the destination's fixed headers, whatever the transformation
sets, and the authentication headers.

When your handler needs a provider header, copy it explicitly. Either keep it
under its own name with a **set header** rule whose value is templated from the
payload, or use the event detail view and the [API](/reference/api/#events),
where all inbound headers are always available.

## Headers we return

On ingest:

| Header | When |
| --- | --- |
| `Content-Type: application/json` | The default acknowledgement, and errors. |
| `Content-Type` per your setting | A [custom response](/receive/custom-response/) — `application/json` or `text/plain`. |
| `Retry-After` | `429`. Seconds to wait. |

On the management API, `Retry-After` accompanies a `429` in the same way.