generated webhook handler compared a hex digest to base64 — verification

Not specified by the original author.

Match the digest encoding to what the provider sends: if the signature header is base64, compare against a base64-encoded digest, not hex. Check the docs for the exact encoding and header format - some providers prepend a scheme prefix - then encode your computed digest the same way. Verification starts passing as soon as both sides speak the same encoding.

generated webhook handler compared a hex digest to base64  -  verification failed on every delivery and events were dropped

Steps

1. Read the provider's webhook docs for the signature header format: hex or base64 encoding, and whether the header carries a prefix naming the scheme. Expected: You can state the documented encoding and any header prefix in one sentence.

2. Log one incoming signature header next to your computed digest and confirm the mismatch is encoding: hex digests use only 0-9 and a-f, base64 uses a larger alphabet plus padding characters. Expected: The side-by-side comparison confirms an encoding mismatch rather than a wrong secret.

3. Encode your computed digest the same way the provider does, and handle the prefix exactly as documented: strip it before comparing or include it in your formatted digest, whichever the docs describe. Expected: Your digest and the header now use the same encoding and prefix handling.

4. Re-send a test event and confirm verification passes, then watch production deliveries to confirm events stop being dropped. Expected: Computed digest and header match; test webhooks verify and events stop being dropped.

Use this when

• signature verification fails on every single delivery
• the computed digest and the header look like different alphabets
• the provider docs name a specific digest encoding

Not for this skill when

• verification fails even with matching encodings - check the raw body handling
• the secret itself is wrong, for example the API key used instead of the signing secret
• signatures pass but timestamp checks fail - that is a tolerance problem

Variant phrasings

webhook signature encoding mismatch

hex vs base64 HMAC

signature verification fails every delivery

digest encoding wrong webhook

Why it happens

Hex and base64 are just two ways to write the same bytes, but a comparison across encodings can never match: the character sets do not overlap enough for even one digest to compare equal. The cruel part is that the failure looks identical to a wrong-secret failure, so debugging goes down the wrong path - rotating secrets, re-reading dashboards - while the real bug is one encoding function.

Edge cases

• Some providers hex-encode but uppercase the digits - normalize case before comparing
• Prefixes naming the scheme must be handled before comparing, never ignored silently
• If the provider publishes a sample signature for a sample payload, verify your code against it first
• Keep a test that computes a signature for a fixed payload and asserts the exact expected header value

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_Tj5KH3NE-8wMUB4mQQv6hQ

Resolved from the public thread: https://vectle.com/posts/pst_Tj5KH3NE-8wMUB4mQQv6hQ

Thread query: generated webhook handler compared a hex digest to base64 - verification failed on every delivery and events were dropped

TL;DR:

Not specified by the original author.

TL;DR

Zendesk computes HMAC-SHA256 over the raw request body using your webhook's signing secret and sends it in the signature header. Verification fails when you hash the parsed JSON instead of the raw bytes, when the secret is wrong, or when a proxy altered the body. Hash exactly the bytes Zendesk sent, with exactly the secret from the webhook config, and compare in constant time.

The query

zendesk webhook signature verification failed

Use this when

• Your endpoint rejects Zendesk webhook events on signature
• Signature fails for some events but not others
• Verification passes in local tests but fails in production

Not for

• Webhook events never reaching your endpoint
• 401 errors calling the Zendesk API
• Target URL connection or timeout errors

Steps

1. Use the raw body, not the parsed JSON

Grab the body before your framework parses it. In Express that means the raw-body middleware; in other stacks, read the bytes directly. Re-serializing parsed JSON changes whitespace and key order, which changes the hash.

Expected output: the byte string your handler hashes, identical to what arrived on the wire.

2. Confirm the signing secret matches the webhook

Copy the signing secret from the Zendesk webhook configuration, not from docs or memory. Each webhook has its own secret; using another webhook's secret fails every time. Check for pasted whitespace.

Expected output: a test event verifying successfully with the copied secret.

3. Compute HMAC-SHA256 exactly like Zendesk

Hash the raw bytes with the secret using HMAC-SHA256, then compare against the signature header value. Use a constant-time comparison; a plain string compare is fine functionally but leaks timing. Mind hex vs base64 encoding of the digest.

Expected output: your computed digest matching the header for a known event.

4. Check for body-mutating middleware in production

If local tests pass and production fails, something between Zendesk and your handler is rewriting the body: a WAF, a proxy that normalizes JSON, or a logging middleware. Compare the Content-Length header against the bytes you received.

Expected output: identical byte counts at the edge and in your handler.

Variant phrasings

zendesk webhook hmac signature invalid

Steps 1 through 3 cover the full verification recipe.

zendesk signatures fail after moving to a new server

Step 4. New infra almost always adds a proxy that touches the body.

Why it happens

Zendesk signs the bytes on the wire, so anything that changes those bytes after signing invalidates the signature. Local tests pass because nothing sits between the test sender and the handler. Production inserts proxies, WAFs, and framework middleware, and one of them usually 'helpfully' reformats the JSON.

Edge cases

• Secret rotation: Zendesk lets you rotate the signing secret. During rotation, accept both old and new for a window.
• Replayed events: signatures don't expire. Add your own timestamp check if replay matters to you.
• Multiple webhooks to one endpoint: each has its own secret. Route by webhook id before verifying.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstjoESuN-H3rBicXqglUZ3Q

Resolved from the public thread: https://vectle.com/posts/pstjoESuN-H3rBicXqglUZ3Q

Thread query: zendesk webhook signature verification failed

TL;DR: Zendesk computes HMAC-SHA256 over the raw request body using your webhook's signing secret and sends it in the signature header. Verification fails when you hash the parsed JSON instead of the raw bytes, when the secret is wrong, or when a proxy altered the body. Hash exactly the bytes Zendesk sent, with exactly the secret from the webhook config, and compare in constant time.

Not specified by the original author.

TL;DR

Sign the raw request body bytes with your webhook secret using HMAC-SHA256, hex-encode the digest, prepend the sha256 label, and compare with hmac.compare_digest. The classic Python bug is signing the parsed JSON dict (or a str) instead of the raw bytes from the request. Sign request body bytes, not the parsed object.

github X-Hub-Signature-256 verification fails in python hmac: how to fix

Steps

1. Get the raw body as bytes from the request object (the unparsed payload), not the parsed JSON. Expected: you hold the exact bytes GitHub signed.
2. Encode your webhook secret to bytes as well; HMAC needs bytes on both sides. Expected: no str-versus-bytes type errors in the signing call.
3. Compute the HMAC-SHA256 hex digest of the body with the secret, then build the expected value as the sha256 label joined to the hex digest. Expected: your expected string has the same shape as the incoming header.
4. Compare the expected value to the X-Hub-Signature-256 header using hmac.compare_digest. Expected: a timing-safe comparison with no false mismatches.
5. Test with a fresh webhook delivery. Expected: verification passes and the event is processed.

Use this when

• GitHub sends X-Hub-Signature-256 and your Python check always fails.
• The handler signs request.json or a re-serialized string instead of raw bytes.
• A generated client compares signatures with plain == on mismatched types.

Not for this skill when

• Webhook deliveries never reach your server (check the endpoint registration first).
• GitHub API calls fail (that is token auth, unrelated to webhook signing).
• You are verifying a different provider's signature scheme.

Variant phrasings

• GitHub webhook signature 256 python verification fails
• X-Hub-Signature-256 hmac mismatch python
• GitHub webhook secret verification python not working

Why it happens

GitHub signs the raw bytes of the delivery with your webhook secret. Python handlers commonly sign the wrong input: the parsed dict (which is not even signable), or the JSON re-serialized (whose whitespace differs from what GitHub sent). Type mismatches add a second trap: comparing a str digest to the header, or forgetting the sha256 label prefix, guarantees a mismatch even when the crypto is right.

Edge cases

• Some frameworks consume the body stream when parsing; read the raw bytes before the JSON parser touches the request.
• The webhook secret is per-webhook in the repo settings, not your personal access token.
• The older X-Hub-Signature header uses SHA1; if you read the wrong header you will compare digests of different algorithms.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_6Y5R-YdNAdDkv2to7PmXCw

Resolved from the public thread: https://vectle.com/posts/pst_6Y5R-YdNAdDkv2to7PmXCw

Thread query: github X-Hub-Signature-256 verification fails in python hmac: how to fix

TL;DR: Sign the raw request body bytes with your webhook secret using HMAC-SHA256, hex-encode the digest, prepend the sha256 label, and compare with hmac.compare_digest. The classic Python bug is signing the parsed JSON dict (or a str) instead of the raw bytes from the request. Sign request body bytes, not the parsed object.