Validation Methods
The ways VYG can authenticate your custom integration webhook requests, and how to choose one.
Choose how VYG verifies your webhooks with the Security check on your data source's Settings tab in Settings → Data sources. Use HMAC when your platform supports it. You can change the method later, but your tool's events are turned away until the tool is changed to match.
| Method | Name in the app |
|---|---|
| HMAC SHA-256 | Signing secret (recommended) |
| Static Header | Secret header |
| Source IP | Allowed IP addresses |
| None | Set up by our team only |
| Method | What you send | Use it when |
|---|---|---|
| HMAC SHA-256 | A signature of the raw body in a header (default). | Your platform can compute an HMAC over the request body. Recommended. |
| Static Header | A fixed secret value in a header you name. | Your platform can attach a custom header but cannot HMAC-sign. |
| Source IP | Nothing extra — requests are accepted by sender IP. | Your platform sends from a small, stable set of IP addresses and can't add a secret. |
| None | Nothing. | Local testing only. Never in production. |
The methods are listed strongest to weakest. Prefer HMAC SHA-256 whenever your platform supports it — a per-request signature is the only method that also proves the body wasn't altered in transit.
HMAC SHA-256
Default and recommended. You compute an HMAC-SHA256 signature over the raw request body using a shared secret, hex-encode it lowercase, and send it in a header. See HMAC Verification for signing examples.
When to use it: any time your sending platform can run an HMAC over the outgoing body. This is the strongest option: it authenticates the sender and detects any modification to the payload, and the secret never travels on the wire.
What you configure:
- Shared secret — generated for you when you connect the integration; shown once. Store it in your platform's secret store.
- Signature header name — defaults to
x-vyg-signature. You can set a different header name if your platform reserves that one.
Example
SECRET='whsec_demo_secret'
BODY='{"type":"checkout_abandoned","event_id":"evt_demo_1","data":{"id":"ck_001"}}'
SIG=$(printf '%s' "$BODY" | openssl dgst -sha256 -hmac "$SECRET" -hex | awk '{print $NF}')
curl -sS -X POST "https://<your-vyg-webhook-host>/custom/<webhookId>" \
-H 'content-type: application/json' \
-H 'x-vyg-topic: checkout_abandoned' \
-H 'x-vyg-event-id: evt_demo_1' \
-H "x-vyg-signature: $SIG" \
--data "$BODY"See HMAC Verification for the full algorithm, language examples, body serialization requirements, and secret rotation.
Static Header
You send a fixed secret value in a header you choose. VYG accepts the request only when that header is present and its value matches the secret you configured.
When to use it: your platform can attach a custom HTTP header to outgoing webhooks but cannot compute an HMAC signature. This is common for no-code postback / pixel tools and older e-commerce platforms. It authenticates the sender via a shared secret, but — unlike HMAC — it does not prove the body is unmodified, and the secret value is sent on every request, so always use HTTPS.
What you configure:
- Header name — the header your platform will send, e.g.
x-my-secret-header. - Header value — the secret value VYG should require. Treat it like a password.
Example — Checkout Champ postback
In Checkout Champ, add a custom header to the postback that targets your VYG webhook URL. Set the header name and value to match what you configured in the VYG setup UI:
Postback URL: https://<your-vyg-webhook-host>/custom/<webhookId>
Method: POST
Custom header: x-my-secret-header: a-long-random-shared-secretcurl -sS -X POST "https://<your-vyg-webhook-host>/custom/<webhookId>" \
-H 'content-type: application/json' \
-H 'x-vyg-topic: checkout_abandoned' \
-H 'x-vyg-event-id: evt_demo_1' \
-H 'x-my-secret-header: a-long-random-shared-secret' \
--data '{"type":"checkout_abandoned","event_id":"evt_demo_1","data":{"id":"ck_001"}}'If the header is missing or the value doesn't match, the request is rejected
with 401 Unauthorized.
Source IP
VYG accepts the webhook only when it arrives from an allowlist of IPv4 addresses or CIDR ranges that you provide. Nothing extra is added to the request — authentication is based purely on the source address of the connection.
When to use it: your platform sends from a small, stable set of IP addresses and cannot attach a secret header or compute a signature. This is a last resort.
IP allowlisting is weaker than a shared secret. It does not authenticate the payload, anyone sharing the same source IP (for example other tenants on the same platform or proxy) can deliver to your endpoint, and provider IP ranges change over time without notice. Keep the list current and prefer HMAC or a static header whenever your platform supports one.
What you configure:
- Allowed IPs / CIDRs — one or more IPv4 addresses or CIDR ranges that your platform sends from.
Use the current outbound IP ranges published by your sending platform. Confirm them with the provider before configuring the allowlist, and update the list when they change.
None
No validation. VYG accepts the webhook without checking any signature, header, or source IP. Brands can't choose this in the app; only our team can set it.
Warning: for testing only. With validation disabled, anyone who knows your webhook URL can deliver events to your account. Never use None in production. Switch to HMAC SHA-256, or at least a static header, before sending real traffic.