Skip to main content
ElasticFunnels can POST a small, standardized JSON payload to a URL on your affiliate’s side every time a commission-relevant event happens — independent of which gateway processed the order. This is the outbound side of affiliate tracking. The payload is intentionally lean: it contains only what an affiliate needs to reconcile a conversion in their own system. Customer details, billing addresses, and product line items are deliberately excluded. If you need rich gateway-aware payloads (with customer info, products, etc.) for your own systems, use the Merchant Postback URLs instead.

How it differs from the legacy macro postback

Affiliates have an existing single-URL GET mechanism with macros like {subid}, {amount}, {txn_id} — that one is unchanged and still works. The system documented here is additive: You can use either, both, or neither.

Configuration

In Affiliates → Edit affiliate → Postback URLs you’ll find:
  1. HMAC Signing Secret — auto-generated per affiliate. Used to verify each request. Keep it secret. You can rotate it at any time; old endpoints will start failing signature checks until they pick up the new secret.
  2. Per-event Postback URLs — one row per supported event. Each row has:
    • URLhttps://example.com/webhooks/affiliate-purchase
    • Bearer Token (optional) — sent as Authorization: Bearer … if set
    • Enabled — toggle without losing the URL
  3. Send test — fires a synthetic payload (with "test": true) for that event.
  4. Recent Deliveries — log of every attempt with HTTP status, payload, response body, and a manual retry button.

Supported events

Affiliate postbacks intentionally do not include shipped, abandon, or failed_payment — those aren’t commission-bearing events.

Request format

HTTP

Signature verification

The signature is HMAC_SHA256(secret, "<X-EF-Timestamp>.<raw_body>"), hex-encoded and prefixed with sha256=. Always verify both the signature and the timestamp (reject anything older than ~5 minutes to defeat replays).

Response handling

Return any 2xx response to acknowledge delivery. Anything else (timeouts, non-2xx, network errors) is recorded as a failure and retried with exponential backoff at 1m, 5m, 30m, 2h, 12h (5 attempts total) before being marked dead. Dead deliveries can be manually retried from the Recent Deliveries log.

Payload schema

Every event uses the same envelope. Numeric amounts may be negative for clawback events (refund, chargeback, subscription_renewal_failed).

Field reference

What’s deliberately not in the payload

  • Customer name, email, phone, address, IP — affiliates don’t need PII to reconcile.
  • Product-level details (SKUs, line items, shipping/billing).
  • Anything specific to the underlying gateway.
If you need that data for your own systems, use the Merchant Postback URLs — those are signed by the merchant secret and contain the full conversion record.

Operational details

  • Deliveries are processed asynchronously.
  • Failed deliveries are retried automatically after their backoff window has elapsed.
  • The Recent Deliveries section in the affiliate form shows delivery attempts and outcomes.
  • Rotating the signing secret immediately invalidates the old one. Coordinate the change with your affiliate before rotating in production.

Testing locally

Point a URL at webhook.site or ngrok, hit Send test for the event you want, and you’ll see the payload + headers arrive within seconds.