Headers we send
Section titled “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.
Headers we read
Section titled “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
Section titled “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, where all inbound headers are always available.
Headers we return
Section titled “Headers we return”On ingest:
| Header | When |
|---|---|
Content-Type: application/json | The default acknowledgement, and errors. |
Content-Type per your setting | A 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.