POSTs it to a URL you own, usually
within a second or two of the event.
Delivery is handled by Svix, which is why every message is signed, retried
on failure, and kept in a searchable log you can replay from.
When to use a webhook
Referly gives you three ways to move data, and they point in different directions:
Reach for a webhook when latency matters or when polling would be wasteful — provisioning an account
the second a referral is created, posting to Slack when an affiliate applies, or keeping your own
database in step with Referly’s without a nightly job.
If you want events landing in another SaaS tool rather than your own code,
Zapier and
Make are webhooks with the handler already written.
How a delivery works
1
Something changes in your program
A sale is recorded, an affiliate is approved, a promo code is issued — whether it came from the
dashboard, an integration, or the API.
2
Referly builds the payload
The changed object is loaded with its useful relations attached — a sale arrives with its
affiliate, referral, and commission already expanded, so you rarely need a follow-up API call.
3
Referly signs and sends it
The payload is
POSTed to every enabled endpoint subscribed to that event type, with
svix-id, svix-timestamp, and svix-signature headers.4
Your endpoint verifies and acknowledges
You check the signature, return a
2xx immediately, and do the real work afterwards.5
Failures are retried and logged
Anything that is not acknowledged is retried automatically on a backoff schedule over the
following hours, and every attempt — with your server’s response body — is stored in the log.
What every payload looks like
Each message is a JSON object with exactly two top-level keys:event, the event type that fired,
and body, the object it happened to.
body contains only the id of the object that was
removed, because there is nothing left to expand. Field-by-field breakdowns for all five object
families are in Payload structure.
What you can subscribe to
There are fifteen event types, in five families. Each family fires on create, update, and delete:
Subscribe only to what you will act on. Each endpoint filters on its own list, so a handler that
only cares about revenue never has to skip past affiliate profile edits. See
Event types for what triggers each one.
There are no payout event types. Payout state reaches you through the commissions on a sale
instead — each entry in a sale’s
commissions array carries payoutCreated and payoutId, so a
sale.updated event tells you when a commission has been rolled into a payout.Requirements for your endpoint
Your receiving URL has to meet four conditions.Publicly reachable over HTTPS
The URL must resolve from the public internet.localhost and private network addresses receive
nothing — while you are developing, use a tunnel such as ngrok or Cloudflare Tunnel and point the
endpoint at the public hostname it gives you.
Acknowledges fast
Return a2xx status as soon as you have verified the signature. Anything else, including a
timeout, counts as a failure and starts the retry cycle. Do not call your database, your billing
provider, or a third-party API before responding — push the event onto a queue and respond, then
process it out of band.
Verifies the signature
The URL is the only secret protecting the endpoint, and URLs leak. Without a signature check, anyone who learns yours can post a fakesale.created and mint commission. Every endpoint gets its own
signing secret; see Verify signatures.
Handles duplicates
Retries, manual resends, and network timeouts all mean the same event can arrive more than once. Treat thesvix-id header as an idempotency key: record the IDs you have processed and drop
repeats, or make the write itself idempotent by upserting on the object’s id.
A minimal handler
Thesvix libraries do the signature check for you. Note that verification runs against the raw
request body — parsing to JSON first and re-serialising changes the bytes and the signature will not
match.
event.event from there — the string is always family.action, so a switch on the
event type is usually all the routing you need.
Where endpoints are configured
Endpoints belong to a single affiliate program. Create them in your dashboard under Settings, then Advanced, then Webhooks, on the campaign whose events you want. Each endpoint has a URL, a description, its own signing secret, and its own list of subscribed event types, and can be disabled without losing its history. If you run several programs, each one needs its own endpoint — a program’s events never reach another program’s URL.Creating endpoints requires a Business or Agency plan and is not available during a free trial.
See plans and features.
What people build with them
- Keep your own database in sync. Mirror referrals and sales into your warehouse as they land, instead of paging the API on a cron.
- React to signups. Push a new
affiliate.createdinto your CRM, start an onboarding email sequence, or open a ticket for manual review. - Trigger fulfilment. Unlock a course, extend a licence, or grant account credit the moment a sale is attributed to a partner.
- Alert on revenue. Post large sales to Slack, or flag a
sale.deletedso finance knows a commission was reversed. - Watch for payout readiness. Use
sale.updatedand thepayoutCreatedflag on the sale’s commissions to know when a commission has moved into a payout run.
Related
Manage endpoints
Create, edit, disable, and delete the URLs Referly sends to.
Event types
All fifteen events and exactly what triggers each one.
Payload structure
Field-by-field reference for every object you can receive.
Verify signatures
Prove a request came from Referly before you trust it.
Retries and logs
The retry schedule, the delivery log, and how to read a failure.
Test and replay
Send sample events and resend real ones while you build.