AI Calling Webhooks: A Guide for Brokerage Teams

A call ends at 14:07 and the trader says yes to a callback on Thursday. If your CRM finds out on Friday, that reactivation is gone, and closing that gap is the whole point of an AI calling webhook integration. The platform posts the outcome to a URL you own the second the line drops, and your handler writes it into HubSpot, Salesforce or the back office before anyone has opened a report.

This guide covers the call events worth subscribing to, what the payload has to carry for a brokerage CRM, how to check a signature, how to survive a duplicate delivery, and what all of it costs at $0.35 per minute. It's written for the ops lead and the developer who'll own the endpoint, not for a vendor deck.

Key Takeaways

• Topcalls fires webhooks on call started, completed, qualified and appointment-booked events, so a brokerage CRM can react within seconds of a trader hanging up.
• The open Standard Webhooks specification recommends a request timeout of 15 to 30 seconds and payloads under 20 KB, so acknowledge fast and process the outcome afterwards.
• HubSpot retries a failed workflow webhook for up to three days, starting one minute after the failure, which is why every handler needs an idempotency check keyed on the call ID.
• ESMA found 74 to 89% of retail CFD accounts lose money, so the disposition a webhook writes back must carry the objection and risk-warning flags the compliance desk asks for.
• Topcalls charges $0.35 per minute all-inclusive with no setup fee or per-seat charge, so the real cost of a webhook integration is your developer's time.

1. What is an AI calling webhook integration for brokers?

AI calling webhook integration is the setup where the calling platform sends an HTTP POST to a URL you control each time a call event happens, and your server writes the result into the CRM, the back office or the MT4/MT5 admin tooling. The broker's systems learn about a callback request, a deposit intent or a do-not-call request within seconds, instead of at the next report export.

Polling is the alternative, and it's a bad fit for a brokerage. A cron job that asks the API for new call records every 15 minutes means a trader who asked for a callback at 14:07 sits in nobody's queue until 14:22 at best. Webhooks flip that around. The platform tells you, and your code only runs when something happened.

Three paths exist, and they aren't exclusive. Topcalls connects HubSpot, Salesforce and Pipedrive out of the box, the automation path reaches 5,000+ tools through Zapier and n8n, and a direct webhook into your own middleware is the route for anything that has to touch the trading platform or a custom back office. Most brokers run the native connector for the CRM and a webhook for everything the CRM can't see. The four connection paths are compared side by side here.

2. Which call events should a brokerage subscribe to?

Subscribe to the completed event first, because it carries the disposition, then add started, qualified and appointment-booked once the completed handler is stable. Topcalls fires all four. In a dormant trader reactivation campaign, completed drives the CRM stage change, qualified opens a task for the account manager, and appointment-booked writes the callback slot to the calendar. Started feeds a live dashboard and nothing else.

One signal brokers forget is the do-not-call request. Whatever field the platform puts it in, that flag has to reach every list as well as the CRM record. Wire the completed handler to suppress the number in the campaign list, the CRM and the email tool in one transaction. A trader who opted out on Monday and got an SMS on Tuesday is a complaint waiting for the regulator, and call outcome automation for brokerage CRMs covers the suppression rules in detail.

Before you write a line of handler code, fill in the Brokerage CRM Integration Planning Checklist: eight sections covering scope, field mapping, dispositions, triggers, sync direction, webhooks, testing and data access, about 90 minutes across two sittings.

3. What should the webhook payload carry for a broker CRM?

The payload needs a join key the CRM can match, the disposition, a timestamp, the call duration, links to the recording and transcript, a short summary, and the do-not-call flag. For a brokerage the join key is the CRM record ID or the MT4/MT5 login, ideally both, because phone numbers change and the same trader can hold two accounts under one number.

• Join key: send the CRM record ID and the platform login you passed in at list import, and reject any delivery that carries neither. Matching on phone number alone will merge two traders sooner or later.
• Disposition: no more than ten values, each with a one-line definition the retention team agreed on. Reached and interested, reached and declined, callback requested, voicemail, wrong number, do not call. Anything finer belongs in captured fields.
• Captured fields: reason for going quiet, objection raised, deposit amount mentioned, preferred callback window. These are what the account manager reads before the follow-up call.
• Compliance fields: whether the risk warning was read and whether the trader asked about leverage. ESMA's CFD measures found 74 to 89% of retail accounts lose money and require a standardised risk warning, and the compliance desk will want proof it was delivered on the call.
• Links, not blobs: a link to the recording and one to the transcript. Don't inline the full transcript.

Send the minimum. The Standard Webhooks spec puts a payload under 20 KB, and there's a second reason for brokers: every byte of personal data in the payload ends up in every log on the path between the platform and the CRM. Shipping links and fetching the transcript when someone opens the record keeps that surface small, which is the shape a GDPR data-processing review expects to see. Topcalls runs against a TCPA, TSR, DNC and GDPR compliance posture, and the payload design is your half of that.

4. How do you verify an AI calling webhook is genuine?

Verify a signature on every delivery and reject anything that fails. The open Standard Webhooks specification signs with HMAC-SHA256 over the message ID, the timestamp and the payload, sent in webhook-id, webhook-timestamp and webhook-signature headers. HubSpot signs workflow webhooks with a SHA-256 hash in an X-HubSpot-Signature header. Any AI calling vendor you connect should offer one of those two shapes, and a shared secret is the minimum.

Why it matters more for a broker than for a SaaS company: a forged completed event could mark a trader as do-not-call, or worse, as agreed to fund, and an account manager would act on either. The endpoint is a write path into your client records. Treat it like one.

Two checks on top of the signature. First, timestamp tolerance: the spec says to confirm the webhook-timestamp is within an allowable window of the current time so a captured request can't be replayed a week later. Second, key rotation: the signature header is a space-delimited list precisely so two keys can be valid at once while you swap them, and the spec puts a symmetric key between 24 and 64 bytes. Put a rotation date in the calendar the day you go live.

5. How do you handle retries and duplicate deliveries?

Make the handler idempotent on the call ID, reply 200 within a few seconds, and do the CRM write afterwards from a queue. Senders retry when they don't get a 2xx: HubSpot retries failed workflow webhooks for up to three days, starting one minute after the failure with gaps of up to eight hours. A retried delivery hitting a non-idempotent handler creates two activities and doubles the reactivation count on your dashboard.

The Standard Webhooks example schedule shows the same pattern: retry immediately, then at 5 seconds, 5 minutes, 30 minutes, 2 hours, 5, 10, 14, 20 and 24 hours, with a recommended request timeout of 15 to 30 seconds. So a handler that calls the CRM API synchronously and waits 40 seconds for a rate-limited response will time out, be retried, and arrive again out of order. Store the raw delivery, acknowledge, then process from the store.

The spec's own suggestion is to use the webhook-id header as an idempotency key and keep seen IDs for a few minutes. For a brokerage, keep them longer. HubSpot can resend three days later, and a Salesforce or HubSpot outage on your side can stretch the gap further, so a table of processed call IDs with a 30-day retention is cheap insurance. The post-call workflow automation guide walks through the queue and dead-letter setup, and the general webhook and API reference for AI voice agents covers the event payloads outside the brokerage context.

Test it before the first live list. Create ten test contacts with your own team's numbers, one per disposition, run a call each, then fire the same completed delivery twice and confirm the CRM shows one outcome. That duplicate test is the one most teams skip and the one that bites hardest at 2,000 calls a day.

6. What does an AI calling webhook integration cost?

On Topcalls, nothing beyond the $0.35 per minute all-inclusive rate, which covers the voice model, telephony, recording, transcription and analytics with no setup fee, no per-seat charge and no minute bundles. The cost that's real is engineering time on your side: an endpoint, a signature check, an idempotency table and the CRM mapping. A proposal arrives within 48 hours of a strategy call, and most campaigns are live in about two weeks.

Whether the developer time is worth it depends on what a reactivated trader is worth to you. Put your dormant list size and average deposit into the dormant trader revenue calculator before deciding how much build time the integration deserves, and see how the customer reactivation solution fits around it. If the trading platform itself needs to trigger or receive calls, the reactivation API requirements post covers the other direction.

7. When doesn't a webhook integration fit?

Skip the custom webhook when the CRM is the only system that needs the outcome and Topcalls already connects it natively, when your dormant list is a few hundred traders and a weekly CSV export does the job, or when nobody on the team can own an endpoint that pages them at night. A handler that breaks silently is worse than a manual export someone checks every Monday.

It also doesn't fit a broker whose compliance desk hasn't signed off on which fields may leave the CRM. Sort the data-processing agreement first. The checklist's data access section lists the questions, and the HubSpot-specific guide covers the case where the native connector is enough on its own.

And if your retention team changes dispositions every month, hold off. A webhook handler hardcodes the mapping; a moving target means a broken mapping and outcomes landing in the wrong stage. Freeze the disposition list for one campaign, run it, then build.

The Brokerage CRM Integration Planning Checklist is the document the CRM admin, the ops lead and the developer fill in together, with a field-mapping table, a disposition table and pass criteria for the go-live test.

If you'd rather walk the mapping through with someone who has wired it for other brokers, book a 30-minute call and you'll have a proposal within 48 hours.