LiveRecoverVYG Developer Docs
Custom IntegrationWebhooks

Validation Methods

The ways LiveRecover can authenticate your Custom E-Com webhook requests, and how to choose one.

LiveRecover can authenticate your Custom E-Com webhook requests in more than one way. You pick the method when you connect the integration on the Settings → Providers → Custom E-Com page, and you can change it later. The right choice depends on what your sending platform is able to do:

MethodWhat you sendUse it when
HMAC SHA-256A signature of the raw body in a header (default).Your platform can compute an HMAC over the request body. Recommended.
Static HeaderA fixed secret value in a header you name.Your platform can attach a custom header but cannot HMAC-sign.
Source IPNothing extra — requests are accepted by sender IP.Your platform sends from a small, stable set of IP addresses and can't add a secret.
NoneNothing.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. LiveRecover recomputes the signature on its side and compares it constant-time.

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, the "sign the bytes you actually send" footgun, and secret rotation.

Static Header

You send a fixed secret value in a header you choose. LiveRecover 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 LiveRecover should require. Treat it like a password.

Example — Checkout Champ postback

In Checkout Champ, add a custom header to the postback that targets your LiveRecover webhook URL. Set the header name and value to match what you configured in the LiveRecover setup UI:

Postback URL:  https://<your-vyg-webhook-host>/custom/<webhookId>
Method:        POST
Custom header: x-my-secret-header: a-long-random-shared-secret
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-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

LiveRecover 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.

Example — Checkout Champ outbound IPs

As a reference, Checkout Champ's known outbound addresses at the time of writing are:

80.248.30.132
80.248.30.141
52.206.5.84
44.219.22.112

Confirm the current list with your platform before relying on it — these addresses can change, and a stale allowlist will cause your webhooks to be rejected.

None

No validation. LiveRecover accepts the webhook without checking any signature, header, or source IP.

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 minimum a static header) before sending real traffic.


More validation methods are planned, including a replay-protected HMAC mode that incorporates a request timestamp.

On this page