Skip to content

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

HeaderWhenValue
Content-TypeThe inbound event had oneCopied from the event.
X-Webhooker-SignatureHMAC signingv1=<hex> — HMAC-SHA256 over {timestamp}.{body}.
X-Webhooker-TimestampHMAC signingUnix seconds at signing time.
X-Webhooker-Event-IdHMAC signingThe event id. Stable across attempts and replays.
your header nameAPI key authThe configured key, verbatim.
AuthorizationBasic authBasic 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.

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

HeaderRead for
Stripe-SignatureStripe verification.
X-Hub-Signature-256GitHub verification.
X-Shopify-Hmac-Sha256Shopify verification.
your signature headerHMAC verification.
your timestamp headerHMAC verification with replay protection.
AuthorizationBasic auth verification.
your header nameAPI key verification.
Content-TypeRecorded and forwarded.

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

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.

On ingest:

HeaderWhen
Content-Type: application/jsonThe default acknowledgement, and errors.
Content-Type per your settingA custom responseapplication/json or text/plain.
Retry-After429. Seconds to wait.

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