Skip to main content

​
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

​
Supported formats

Same six formats as Inbound Webhooks verification: 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 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.
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 for current limits.

​
Next steps