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

# Webhook Signing overview

> Sign outbound webhook events in any of six HMAC formats — Stripe, GitHub, Slack, AWS-SNS-HMAC, KnoxCall legacy, or a custom header. The recipient verifies the signature and rejects forgeries.

# Webhook Signing overview

KnoxCall's **Webhook Signing** is HMAC-as-a-service for outbound events. When KnoxCall fires a webhook (workflow output, alert dispatch, custom integration), the payload is signed with HMAC-SHA256 in the format the recipient expects. They verify the signature and trust the bytes; nobody can forge an event without the shared secret.

This is the inverse of [Inbound Webhooks](/essentials/inbound-webhooks/overview) — same wire formats, opposite direction.

## Why use it

| Problem                                          | Without signing                                   | With KnoxCall signing                                                                                                 |
| ------------------------------------------------ | ------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------- |
| Receiver gets a webhook with a sensitive payload | Anyone who learns the URL can forge events        | Without the secret you can't forge a signature; receiver rejects                                                      |
| Each integration uses a different signing scheme | One-off code per recipient                        | Pick a format from the dropdown; KnoxCall emits headers the recipient already validates                               |
| Rotating the signing secret                      | Update KnoxCall + the recipient atomically (race) | Stripe-format accepts multiple `v1=` simultaneously — drop in the new secret, rotate the upstream, retire the old one |
| Replay attacks                                   | Receiver re-runs the same event twice             | Formats with timestamps (Stripe / Slack) include `t=` so the receiver enforces a 5-minute window                      |

## Supported formats

Same six formats as [Inbound Webhooks verification](/essentials/inbound-webhooks/format-guide):

| Format      | Header                                    | Replay-safe? | Use case                                                      |
| ----------- | ----------------------------------------- | ------------ | ------------------------------------------------------------- |
| **stripe**  | `Stripe-Signature: t=<unix>,v1=<hex>`     | yes          | Stripe-compatible receivers, anything that adopted the format |
| **github**  | `X-Hub-Signature-256: sha256=<hex>`       | no           | GitHub, Postmark, SendGrid-shape receivers                    |
| **slack**   | `X-Slack-Signature: v0=<hex>` + timestamp | yes          | Slack-compatible event handlers                               |
| **aws-sns** | `x-amz-sns-signature: <base64>`           | no           | KnoxCall-shaped SNS receivers (not real AWS RSA-SNS)          |
| **legacy**  | `X-Webhook-Signature: sha256=<hex>`       | no           | KnoxCall-to-KnoxCall flows; older subscribers                 |
| **custom**  | caller-named, `sha256=<hex>`              | no           | Internal tools that don't match a named scheme                |

The **killer test** that proves the formats are right: KnoxCall's `stripe`-format output is verified end-to-end by Stripe's own SDK in the test suite. If `stripe.webhooks.constructEvent` accepts our header, the wire format is byte-correct. The same kind of round-trip test exists for every format, and KnoxCall's own [Inbound Webhooks](/essentials/inbound-webhooks/overview) verifier is the inverse — outbound + inbound share the same six format definitions, so the round-trip is structurally guaranteed.

## How recipients verify

Every format follows the same pattern: HMAC-SHA256 over a defined byte sequence (often the raw body, sometimes prefixed with a timestamp), encoded as hex or base64, dropped into a known header. The recipient recomputes the HMAC with the shared secret and compares constant-time.

For the wire-level details (what bytes get signed, what the header looks like, replay-window semantics), see the [Inbound Webhooks format guide](/essentials/inbound-webhooks/format-guide) — both directions speak the same protocol.

## Where signing happens in KnoxCall

Webhook Signing applies anywhere KnoxCall fires HTTP events outward:

* **Workflows** — emit signed events to integrations.
* **Alerts** — sign Slack-format webhook deliveries to your incident channel.
* **Custom dispatcher** — pick a format on the subscription; KnoxCall handles the signing.

The format is per-subscription, not global, so different recipients can each get the format they expect.

## Choosing a format

* **Talking to a real provider that documents a scheme?** Use the matching format. Stripe receivers expect `stripe`, Slack receivers expect `slack`, GitHub-shaped receivers expect `github`, etc.
* **Talking to your own service?** Use `legacy` (KnoxCall's default) for KnoxCall-to-KnoxCall flows, or `custom` if you want to pick the header name yourself.
* **Talking to an integration that doesn't document a scheme?** `legacy` or `custom` — most receivers will accept "HMAC-SHA256 of the body in this header" if you tell them which header to read.

## Plan limits

Multi-format webhook signing (everything except `legacy`) is gated to paid tiers — Pro and above. Free / Starter ship with `legacy` only. See [pricing](https://knoxcall.com/pricing) for current limits.

## Next steps

* [Inbound Webhooks overview →](/essentials/inbound-webhooks/overview) — verify HMAC-signed webhooks coming *in* from external providers
* [Format guide →](/essentials/inbound-webhooks/format-guide) — wire-level details (shared with inbound)