Verifying Webhook Signatures
Every webhook from KnoxCall includes an HMAC-SHA256 signature. Verifying this signature ensures the webhook:- Came from KnoxCall (not an attacker)
- Wasn’t modified in transit
How Signatures Work
When KnoxCall sends a webhook:- Takes the JSON payload
- Signs it with your webhook’s secret key using HMAC-SHA256
- Includes the signature in the
X-Webhook-Signatureheader
- Get the signature from the header
- Compute the expected signature using the same secret
- Compare them (timing-safe comparison)
- Reject if they don’t match
Implementation Examples
Node.js (Express)
Python (Flask)
PHP
Go
Ruby (Sinatra)
Getting Your Webhook Secret
View Secret
- Click Automation in the sidebar, then select Webhooks
- Click on your webhook
- Click Reveal Secret
- Copy the secret
a1b2c3d4e5f6... (64 hex characters)
Regenerate Secret
If your secret is compromised:- Click Regenerate Secret
- Copy the new secret immediately
- Update your endpoint with the new secret
Common Mistakes
1. Parsing JSON Before Verification
Wrong:2. Wrong Secret
Symptoms:- All signatures fail
- No intermittent issues
- Copy secret directly from KnoxCall
- Ensure no extra whitespace
- Check environment variable is set
3. Non-Timing-Safe Comparison
Wrong:4. Encoding Issues
Symptoms:- Signatures fail for certain payloads
- Works for simple data, fails for special characters
- Use raw bytes, not decoded strings
- Ensure UTF-8 encoding throughout
Security Best Practices
1. Always Verify Signatures
Never process webhooks without signature verification:2. Store Secrets Securely
- Use environment variables (not hardcoded)
- Rotate secrets periodically
- Use secrets management services in production
3. Reject Missing Signatures
4. Log Verification Failures
Monitor for repeated failures - could indicate an attack:5. Use HTTPS Only
Signatures protect against tampering, but HTTPS protects against eavesdropping:- Always use HTTPS endpoints
- Reject HTTP in production
Debugging Signature Issues
Step 1: Log Both Signatures
Step 2: Check Payload
Step 3: Verify Secret
Step 4: Test with Known Values
Use the KnoxCall test feature and compare:- Test payload vs what you receive
- Expected signature vs what you compute
Who can see a webhook’s signing secret
Revealing an existing webhook’s signing secret is a reveal. In the dashboard this is a Class B reveal: only an Owner or an Admin can do it (an Editor cannot, even with Reveal secrets turned on; that setting covers secret values, certificates and credentialed workflow tests only), and every use asks for a fresh second factor (an authenticator code, a passkey or a security key; an emailed code does not count). Each use writes aplaintext.reveal entry to the audit log before anything is shown, and counts against the same per-person reveal budget as showing a secret’s value (60 per 5 minutes). If the audit entry cannot be written, or the budget cannot be counted, the request is refused rather than served. On the Management API (/v1) the signing secret is returned only in the response that creates the webhook. A tenant policy that denies
webhook:reveal_secret still refuses before your verification is spent.
The secret returned when you create a webhook or regenerate its secret is different: it is
minted for you in that request, nothing existing leaves, and it is shown once without a
verification.
Next Steps
Testing Webhooks
Test your signature verification
Webhook Logs
Debug webhook issues
Creating Webhooks
Configure webhook settings
Webhooks Overview
Learn about webhooks
Statistics
- Level: intermediate
- Time: 8 minutes
Tags
webhooks, security, signatures, hmac, verification