Webhooks

Request headers

The headers every delivery to your app carries, and the ones a destination cannot set.

Headers we add

Every attempt carries these headers, as well as the sender’s own and the destination’s authentication.

HeaderHolds
webhook-idThe event’s ID. The same on every attempt, and when a delivery is sent again
webhook-timestampWhen this attempt was sent, in seconds since 1 January 1970
webhook-signaturev1, and the signature, in base64. See Verify deliveries to your app
X-Hooks-Delivery-IdThe delivery’s ID. A delivery sent again has a new one
X-Hooks-AttemptThe attempt number, from 1

Use webhook-id to recognise an event you have already handled. See At least once.

The sender’s headers

The headers the webhook was received with are sent on, including the sender’s own signature headers, so your app can still check them. These are left out, because they only mean something on the way:

  • Host, Content-Length, Transfer-Encoding, Connection, Keep-Alive, Upgrade, TE, Trailer, and Expect
  • User-Agent, Accept-Encoding, Forwarded, and headers starting with X-Forwarded-
  • Proxy headers, such as Proxy-Authorization
  • Any webhook-id, webhook-timestamp, webhook-signature, or X-Hooks- header the sender set

A destination’s authentication replaces a sender’s header of the same name, such as Authorization.

Headers a destination cannot set

A destination’s header authentication cannot use a header we set ourselves:

  • Host, Content-Type, Content-Length, Transfer-Encoding, Connection, and User-Agent
  • webhook-id, webhook-timestamp, and webhook-signature
  • Any header starting with X-Hooks-

Last updated