Webhook HMAC signature verification (SHA-256): a practical receiver checklist

Webhooks are only safe if receivers can verify authenticity.

If you're integrating with Gestio, start here:

• ERP webhooks (Dubai)

What "HMAC signed webhook" means in practice

At a high level:

• Sender computes an HMAC SHA-256 signature over the payload (often with a timestamp).
• Receiver recomputes the signature with the shared secret.
• If signatures match, accept. If not, reject.

The critical detail is that the receiver must verify every request, not just "most of them".

Receiver checklist (implementation-first)

1. Read the raw request body exactly as received

Do not parse + reserialize JSON before verifying signatures. Verify the exact raw bytes.

2. Include a timestamp in the signed payload (and validate it)

Timestamped signatures help prevent replay attacks. The receiver should reject requests that are too old.

3. Use constant-time comparison

Never compare signatures with a naive string equality if your environment has a safer constant-time compare. This reduces timing side-channel risk.

4. Enforce idempotency

Even with signing, webhooks will be retried. Receiver handlers must be idempotent:

• store an idempotency key or event id
• ignore duplicates safely

5. Plan for secret rotation

Rotation is normal operations, not an exception. A robust receiver supports:

• current secret
• previous secret (for a short overlap window)

That allows rotation without downtime.

The operational benefit: fewer "ghost failures"

When verification is strict and consistent:

• spoofed webhooks get rejected
• bugs get detected quickly
• retries become safe because handlers are idempotent

What to do next

• Set up the subscription and signing: ERP webhooks (Dubai)
• If you are also using developer integrations, use scoped access: API key management (Dubai)