ANY OTHER CRM
Any CRM, over one API
There is one deep native connector today. For every other system the answer is not a waiting list — it is a REST API with scoped keys and signed webhooks, which is the same machinery the native connector itself is built on.
A connector is a convenience, not a capability. Everything a native connector does — put an inbound message where your team will see it, send a reply back, report what happened to it — is three API calls and a webhook. If your system can make an HTTPS request, it can do all three today.
What “connected over the API” actually means
Three movements, and none of them needs anything from us but a key.
A customer writes to your number
We store the message and post a signed webhook to your endpoint. You decide what it becomes in your system: a task, a note on a record, a row in a queue, a notification to whoever owns the account.
Your system replies
One API call, carrying an idempotency key so that a retry from your own job queue cannot send the customer the same message twice. Inside the free-text window it can be any message; outside it, an approved template.
We tell you what happened to it
Delivery and read state arrive on the same webhook endpoint, so the state in your own system is a fact rather than an assumption about whether a send worked.
What you are responsible for, honestly
A connector hides these; the API does not, and that is the trade.
Deciding which record a message belongs to
Matching a phone number to a customer record is a judgement about your own data. A native connector makes it for you; over the API you make it, which is also why it can be right for your data model rather than approximately right.
Somewhere for your team to read it
If your system has no inbox, your team can keep using ours for the conversation while your system holds the record. The two are not exclusive — the same number can be worked in both.
Handling a webhook you could not process
A 200 means delivered. Events are held for an endpoint we disabled after a long run of failures, not for one that answered and then dropped the payload.
Which connector gets built next
The one a paying customer asks for, and we will say so rather than list nine.
There is a real temptation to publish a page of CRM logos marked coming soon. We are not going to: a roadmap of nine integrations with one shipped is a promise about eight things nobody has committed to, and a reader can tell.
What is true: the native connector that exists was built because a customer needed it, the API exists so nobody has to wait for that, and the next native connector will be chosen the same way. If you tell us which system you run, that is the whole of the prioritisation process.
Where it sits
The REST API and webhooks
Scoped keys, the required idempotency key, and the webhook queue that holds.
CRM connectors
What is native today, and what runs over the API today.
ChatBridge24 without a CRM
If the answer turns out to be that you do not need the CRM in the loop.