RexaThe short answer
Rexa ships no pre-built CRM connector. What it does ship is a signed webhook feed and a function-calling mechanism, which together keep any CRM that accepts an HTTP request up to date. You subscribe an endpoint to the events you care about, verify the signature, and write the outcome into your own system on your own field names.
Last reviewed
Which events carry a call outcome?
The ones most CRM syncs subscribe to are `session.ended`, `session.disposition_set`, `campaign.contact_completed` and `campaign.contact_failed`. Disposition is worth understanding separately: it is derived asynchronously after the call and fires after `session.ended`, so a sync that only listens to the end of the call will miss it.
Two more are useful and easy to overlook. `campaign.contact_dispatched` tells you a contact has been attempted, which is what you want if your CRM shows call attempts rather than only results. And `campaign.inbound_received` fires when an inbound call matches a prior outbound session in the same campaign — it arrives before the normal lifecycle events specifically so you can trigger a "callback received" action first.
Every delivery carries the same envelope: an `id`, the event `type`, your `tenant_id`, a `created_at` timestamp and a `data` object whose shape depends on the event.
How do I know the request really came from Rexa?
Each request carries `X-Webhook-Signature` in the form `sha256=<hex>`, along with `X-Webhook-Timestamp` in unix seconds, `X-Webhook-Event` naming the event type and `X-Webhook-Id` identifying the delivery. The signature is an HMAC-SHA256 over the timestamp, a literal full stop, and the request body.
Verify against the raw bytes you received, not a re-serialised copy of the parsed JSON — a whitespace difference is enough to invalidate a correct signature. Include the timestamp in the check too: rejecting anything outside a five-minute drift window is what stops a captured request being replayed at you later. Compare the digests in constant time.
What happens if my CRM is down?
Deliveries retry on a fixed curve rather than exponential backoff with jitter: 30 seconds, then 1 minute, 5 minutes, 15 minutes, 1 hour, 3 hours, 6 hours, 12 hours and 24 hours. That is nine attempts spanning roughly 48 hours. The curve is fixed precisely so the times are legible — you can look at a delivery log during an incident and know when the next attempt lands.
After the ninth attempt a delivery is marked permanently failed. Three consecutive permanent failures on the same endpoint raise a `webhook.endpoint_disabled_notice` so a broken receiver is not silently dropping your call outcomes for a week.
Can the agent read CRM data during the call?
Yes, through functions rather than webhooks — the direction is reversed. You register a function with a name, a description the model uses to decide when to call it, a JSON Schema for its arguments, an HTTPS URL and a timeout between 1 and 30 seconds. Mid-conversation the agent calls your endpoint and speaks the result.
A call can have up to twenty functions in total. That is the mechanism for "look up this customer’s open ticket before answering" as opposed to "tell my CRM what happened afterwards".
Frequently asked questions
- Does Rexa have a Salesforce or HubSpot connector?
- No. There is no marketplace app, no OAuth flow and no field mapping UI for either. Both are reachable through the webhook feed and through mid-call functions, which is genuinely useful and genuinely requires someone to write the receiving code or wire it up in an automation platform.
- How do I stop a retry creating a duplicate record?
- Use the `id` in the event envelope as an idempotency key. It identifies the event rather than the attempt, so a redelivery after your endpoint timed out arrives with the same id you already processed. Record it and no-op on a repeat.
- Can the agent look up an account while the caller is still on the line?
- Yes. That is what functions are for. The agent calls your HTTPS endpoint mid-conversation, waits up to the timeout you configured, and uses the answer in what it says next. Post-call webhooks handle the other direction.
Scope, limitations, and sources
This is the part to be blunt about: Rexa does not publish a Salesforce, HubSpot, Pipedrive or Zoho application. There is no OAuth connection flow, no object mapping screen, no field picker, and nothing to install from a vendor marketplace. Somebody has to write the code that receives an event and writes the record, or route it through an automation platform that can. What you get instead is a documented event catalog, a signature scheme, and a retry curve — which is more durable than a connector but is not the same as one. Rexa also cannot see inside your CRM: it knows only the HTTP status your endpoint returned, so a 200 on a request your system then failed to process looks like success.
Sources
- Outbound webhook event catalog, signature headers and the delivery retry schedule. rexa.ai (accessed )
- Mid-call function definitions, parameter schemas, timeout bounds and spoken waiting messages. rexa.ai (accessed )
Spotted something out of date or wrong? Tell us on the contact page and we will correct it and update the review date.