HMAC signature mismatch

When your endpoint computes a different HMAC than what e-bon sent in X-EBon-Signature, almost every cause is one of three: you re-serialized the JSON body before hashing, you are using the previous secret after a rotation, or you are using the wrong secret altogether (e.g. the test webhook's secret on the production webhook).

Likely causes

• Re-serialized JSON body — you parsed the request as JSON and then re-stringified it before hashing. Different serializers reorder keys, change whitespace and reformat numbers; the hash will differ. The signature is over the raw bytes of the request body.
• Wrong secret after rotation — POST /api/v1/org/webhooks/{id}/rotate-secret returns a new whsec_… value once. If you rotated but did not update the secret stored by your endpoint, every subsequent delivery will fail verification.
• Wrong secret for the wrong webhook — common when copy-pasting the secret of the test webhook into the production endpoint, or vice versa. Each subscription has its own secret.
• Wrong algorithm or encoding — the algorithm is HMAC SHA-256, the digest is lowercase hex, and the header value is the literal string sha256=<hex>. Hex (not base64), lowercase, single-line.
• Clock skew — X-EBon-Timestamp is the dispatch attempt timestamp. If you reject deliveries based on a tight skew window (e.g. ±2 minutes), and your server clock has drifted, you will reject otherwise valid requests. The signature itself does not include the timestamp — clock skew only matters if you add a replay-protection check on top.

How to verify

Reproduce locally against a captured payload using openssl:

# RAW_BODY = the exact bytes you received in the POST body, no reformatting.
# SECRET   = your webhook's whsec_… value.

printf '%s' "$RAW_BODY" \
  | openssl dgst -sha256 -hmac "$SECRET" -hex \
  | awk '{print "sha256="$2}'

The result must equal the value of the X-EBon-Signature header byte-for-byte. If it does not, the body you fed openssl differs from the body e-bon hashed — almost always because of re-serialization.

To rule out a stale secret, fetch the current subscription metadata. The secret itself is not returned, but you can confirm enabled, events, url and failureCount:

curl https://api.e-bon.ro/api/v1/org/webhooks/{webhookId} \
  -H "Authorization: Bearer <jwt>"

Then send a controlled test event and compare against the captured request:

curl -X POST https://api.e-bon.ro/api/v1/org/webhooks/{webhookId}/test \
  -H "Authorization: Bearer <jwt>"

Fix

Still stuck?

Open a support case at support@e-bon.ro or e-bon.ro/contact with the webhookId, a captured X-EBon-Delivery-Id, the exact X-EBon-Signature header you received, and the digest your endpoint computed (no need to share the secret).