- How does webhook signature verification work?
- Webhook signature verification recomputes an HMAC-SHA256 hash over the timestamp and raw request body using your shared secret, then compares it to the signature header the sender attached — a match confirms the payload really came from that sender and was not altered in transit.
- Is my signing secret sent to SkedCast’s servers?
- No. The HMAC-SHA256 computation runs entirely in your browser using the Web Crypto API — the secret, body, and header you type never leave your device.
- Does this match SkedCast’s real signing scheme exactly?
- Yes. The signed payload construction (`"<timestamp>.<rawBody>"`, HMAC-SHA256, hex-encoded) is copied from the same module the platform’s outbound webhook dispatcher uses, and is pinned against the backend’s own test fixture so it cannot silently drift.
- Why does a correct-looking signature still fail?
- The most common cause is the request body not being byte-for-byte identical to what was signed — re-serializing JSON, changing whitespace, or trimming a trailing newline all change the signature.
- What does the timestamp freshness check protect against?
- It prevents a captured, valid delivery from being replayed later — SkedCast’s own verifier rejects a timestamp more than 5 minutes old or in the future, and this tool applies the same window.
- What is the difference between this and Standard Webhooks?
- SkedCast also emits Standard Webhooks-format signatures alongside the `X-SkedCast-Signature` header; this tool tests the `X-SkedCast-Signature` scheme specifically, which is the Stripe-style format most integrators already recognize.
- Can I use this to sign requests for a different platform?
- The underlying HMAC-SHA256 math is generic, but the exact header format and signed-payload construction here matches SkedCast’s scheme specifically — another platform’s scheme may differ.