For over a decade, the default way a phone system talked to a CRM was the same everywhere: a softphone panel, embedded as an iframe, sitting in a tab. That default is going away. One CRM after another is retiring its embedded-widget API in favor of voice as a native, API-driven object living inside the platform itself.
Salesforce is the clearest case. It has set February 28, 2028 as the end-of-life date for Open CTI, the API that has let phone systems draw a softphone panel inside Salesforce since 2012, in favor of Service Cloud Voice. New Agentforce Service orgs can’t even provision the old API anymore. Zendesk and Microsoft Dynamics are headed the same way. Fourteen years of contact-center plumbing is on its way out, and this isn’t really a Salesforce story. It’s a CRM industry story, and it’s a big part of why we’ve been rethinking how Exotel talks to CRMs.
CRM as the interface, CCaaS as the backend
The embedded-widget model did one job: let a third-party phone system draw its own UI inside the CRM’s tab. It was usually provider-agnostic, so any telephony vendor could integrate against the same API. But at its core it was still a bolted-on iframe talking to a system the CRM couldn’t see inside.
What’s replacing it looks different. Voice becomes a native object in the CRM itself, wired directly into the CRM’s own routing, supervisor tools, transcription, and AI layer. The contact center doesn’t go away. It just moves behind the CRM’s own APIs and events, and the CRM becomes the only thing agents, and increasingly AI, actually look at.
Part of this is that an AI agent can’t click a screen. If a CRM’s AI layer is going to read call state or trigger a transfer, it needs a method it can call and an event it can listen for, not a UI built for a human’s mouse. Part of it is plain business gravity: the more of the contact-center logic a CRM can pull inside itself, routing, presence, next-best-action, the less it needs a separate CCaaS platform doing that work outside it. Either way, telephony stops being something the CRM merely displays and starts being something it calls directly.
What that means on our side
If CRMs are moving toward calling into the contact center instead of rendering it, the contact center needs a contract built for exactly that: public methods and events, not internal IDs or database rows, so a CRM can integrate without ever knowing our schema.
That’s the layer we’ve been building out for our voice product. Agent actions such as login, state changes, accept and reject, hold, transfer, conference, disposition, and callback are becoming public methods that take only external identifiers (a user ID, a campaign ID, a call ID) and emit a matching event back, say a call getting accepted, a transfer completing, an agent’s state changing, each with a status, a correlation ID, and a timestamp. It’s still a work in progress on our end, but the shape of it is set. Nothing tied to our internal schema, all of it reachable through our toolbar SDK, so a CRM can build against a stable contract instead of a fragile adapter.
It’s the same move CRMs are making on their own side, just from the CCaaS end of the wire.
And this is just the start
Voice is where we’re focused first. Extending the same event contract to our omnichannel platform, streaming those events over WebSockets, and handling multi-call orchestration are the natural next steps once this lands. The end state we’re aiming for is one consistent telephony contract that any CRM can build a UI-less, backend-resident integration against, with no internal ID and no iframe required.
CRMs retiring the embedded phone widget was never really about any one vendor. It’s a preview of what every CRM integration is going to expect next.
Sources: Salesforce Ben — Open CTI Reaches End of Life, Revenue.io — Salesforce Open CTI Sunsetting, Salesforce Developers — Open CTI End of Life, Grazitti — Open CTI to Salesforce Voice Transition Strategy.