Custom HMAC
Connect any provider that signs with HMAC-SHA256 over the raw body
Use Generic HMAC SHA-256 when your partner signs the raw body with HMAC-SHA256 and does not fit a named mode. You configure the signature header, its encoding and an optional prefix.
Setup
1. Create the Wexio Connection
Go to New connection → Inbound, set Authentication mode to Generic HMAC SHA-256 and fill in these fields.
| Field | Description |
|---|---|
| Signing secret | The shared secret the partner uses to sign |
| Signature header name | Where the signature lands, case-insensitive (for example X-Signature, My-Sig-256) |
| Encoding | Hex (most providers) or Base64 (Shopify) |
| Header prefix (optional) | Optional prefix to strip from the value (for example sha256=, v1=) |
The signing input is always the raw body, with no timestamp prefix and no path concatenation. If your partner includes a timestamp in the signing input, verify in an n8n or Make proxy and forward a plain Shared Secret request to Wexio.
2. Point the Partner at Wexio
The steps depend on the partner. Paste the Wexio endpoint URL as the webhook destination and share the signing secret with both sides.
3. Resolve Contacts and Bind a Flow
This is the same as for every inbound connection. Set the identifier mapping, capture the schema, then bind a Webhook Received trigger.
How Verification Works
Wexio reads <headerName> from the request
├─ strips <prefix> if set
├─ decodes as <encoding>
└─ timing-safe compares against
HMAC-SHA256(<signing secret>, <raw body>)Limits of This Mode
Use another route when your partner does any of these:
- Timestamp-prefixed signing (Stripe, Slack, Paddle, Revolut, Svix). Use the matching named mode.
- Asymmetric signatures (RSA, Ed25519, ECDSA, JWS). Proxy through n8n or Make for now.
- A signing input that includes the URL or method (for example Twilio, Square). Proxy.
- Multiple signatures per header during rotation. Only the Stripe, Paddle and Svix modes parse multi-value headers. For custom HMAC, rotate by updating the secret in one step.
Presets
Many providers have a chip under Provider presets > HMAC presets that fills these fields. Check them first. The chip label matches the provider name below.
| Provider | Header name | Encoding | Prefix |
|---|---|---|---|
| GitHub | X-Hub-Signature-256 | Hex | sha256= |
| Bitbucket Cloud | X-Hub-Signature | Hex | sha256= |
| Shopify | X-Shopify-Hmac-Sha256 | Base64 | - |
| Razorpay | X-Razorpay-Signature | Hex | - |
| PagerDuty | X-PagerDuty-Signature | Hex | v1= |
| Linear | Linear-Signature | Hex | - |
| Dub | Dub-Signature | Hex | - |
If your provider is not listed but follows the same pattern, set the four fields manually. Mailgun, Zendesk and HubSpot have their own modes because their signature covers more than the body. Paystack, Vercel and GitLab have their own modes too, under Dedicated providers. For a provider whose scheme fits none of these, such as Netlify, use a proxy.
Troubleshooting
| Symptom | Fix |
|---|---|
UNAUTHORIZED: HMAC signature mismatch | Check the encoding (hex or base64), the prefix, whether a reverse proxy reformats the body bytes, and whether the partner puts a timestamp in the signing input |
UNAUTHORIZED: Missing <header> | The partner is not sending the header you configured. Check the spelling (case-insensitive) and that signing is enabled on the partner side |
UNAUTHORIZED: Connection is missing its signing credential | The connection has a mode but no signing secret. Paste one with Change under Authentication |
Related
- Inbound Webhooks - auth modes, contact resolution and response codes
- Webhook Received - the trigger that starts your flow
- Integrations - the support matrix and per-provider setup
- Webhook History - check why a request failed