Also known as: HTTP Push API, Web Callback, Reverse API, HTTP Callback
A webhook is an automated message an application sends to a URL you control the moment a specific event happens. Instead of you repeatedly asking a system 'is there anything new?', the system pushes the data to you as soon as the event occurs, carrying a small payload describing what happened.
For IBs and affiliates, the events that matter are lifecycle events on referred clients: a new registration, a first-time deposit, a KYC approval, a trade close, or a rebate calculation. When any of these fires, the broker's platform sends an HTTP POST request to your endpoint with a JSON body — client ID, event type, amount, timestamp — and your system reacts in real time.
Technically a webhook is just a normal HTTP request from the broker's server to yours. You register an endpoint URL in the broker's partner dashboard, the broker POSTs JSON to it when the event happens, and your server responds with a 200 status to acknowledge receipt. If your endpoint is down or slow, well-designed senders retry with backoff, which is why idempotent handling matters.
For example, an IB registers the endpoint https://crm.example.com/hooks/deposit. A referred trader deposits $500. Within a second or two the broker POSTs {"event":"first_deposit","client_id":"88214","amount":500,"currency":"USD"} to that URL, the IB's CRM tags the lead as funded, and an automated onboarding email goes out — no polling, no delay, no manual export.
You expose a public HTTPS endpoint and register its URL with the broker. When a subscribed event occurs, the broker's server sends an HTTP POST to that URL with a JSON payload describing the event. Your endpoint parses the payload, does its work (update CRM, trigger an email, log a rebate), and returns a 200 response to confirm delivery.
Because the internet is unreliable, robust webhook systems include a signature header so you can verify the request genuinely came from the broker, a unique event ID so you can ignore duplicates, and automatic retries if your endpoint returns an error or times out. Building your handler to be idempotent — processing the same event twice produces the same result — is the single most important reliability practice.
Stand up an HTTPS URL (a serverless function or a CRM inbound hook) that can accept POST requests.
In the partner dashboard or via support, subscribe your endpoint to the events you care about (deposit, registration, trade close).
Check the signature header on every incoming request so only genuine broker events are processed.
Use the event ID to skip duplicates, then run your action — update the record, send the message, book the rebate.
Return a 200 quickly; do heavy work asynchronously so the sender does not time out and retry.
Why it matters for partnership: Webhooks let you react to a referred client's deposit or first trade in seconds instead of hours, powering instant onboarding, real-time dashboards, and timely rebate reconciliation. Faster, automated follow-up lifts activation and retention without a single manual export.
An IB on cTrader's partner program configures a webhook to their HubSpot CRM. The moment a referred client makes a first deposit, the broker POSTs the event, HubSpot tags the contact 'funded', and a pre-built 'Welcome and Risk Guide' email sends automatically. The IB's activation rate on new deposits rises because the follow-up lands within minutes, not the next business day.
| Attribute | Webhook (push) | Polling an API (pull) |
|---|---|---|
| Who initiates | The broker, on each event | You, on a repeating schedule |
| Latency | Near real time (seconds) | As slow as your polling interval |
| Resource use | Efficient; only fires on events | Wasteful; most requests find nothing new |
| Reliability need | Your endpoint must be always up | You control timing; can retry later |
| Best for | Instant reactions to client events | Bulk reconciliation and reporting |
Use Zapier, Make, or Pipedream to catch a broker's webhook and route it to your CRM and email tools with no server to maintain — but still verify the signature and dedupe on the event ID.
Leaving the endpoint unauthenticated lets anyone POST fake 'deposit' events and corrupt your data; always verify the sender's signature and treat duplicate events idempotently.
With an API you request data when you want it (pull). With a webhook the other system sends data to you automatically when an event happens (push). Many platforms offer both.
Not necessarily. No-code tools like Zapier, Make, and Pipedream can receive a broker's webhook and connect it to your CRM and email without writing code.
Use an HTTPS endpoint, verify the signature header the broker sends, and ignore any request that fails verification. Never act on unauthenticated data.
Most brokers retry delivery with backoff for a period. Once your endpoint returns a 200 again it should receive the queued events, but confirm the retry policy in the broker's docs.
Retries and network hiccups can deliver duplicates. Store each event's unique ID and skip any you have already processed so you never double-count a deposit or rebate.
No. Availability depends on the broker's partner platform. Ask your affiliate manager which events are supported and whether they offer polling APIs as an alternative.
Commission rate stops being the deciding factor once you're managing sub-IBs at scale — this guide covers the back-office infrastructure a broker needs: tier depth, API …