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
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 — 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:| 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 |
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 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 — 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.
Choosing a format
- Talking to a real provider that documents a scheme? Use the matching format. Stripe receivers expect
stripe, Slack receivers expectslack, GitHub-shaped receivers expectgithub, etc. - Talking to your own service? Use
legacy(KnoxCall’s default) for KnoxCall-to-KnoxCall flows, orcustomif you want to pick the header name yourself. - Talking to an integration that doesn’t document a scheme?
legacyorcustom— 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 exceptlegacy) is gated to paid tiers — Pro and above. Free / Starter ship with legacy only. See pricing for current limits.
Next steps
- Inbound Webhooks overview → — verify HMAC-signed webhooks coming in from external providers
- Format guide → — wire-level details (shared with inbound)