A CPaaS sells building blocks: numbers, SIP or HTTP call control, media (TTS, gather DTMF, recording), and SMS / MMS / sometimes RCS. An application you write decides when to dial, what to play, and how to webhook on events. That is the opposite of a packaged PBX, where the vendor's dial plan is the product.
CPaaS vs UCaaS vs CCaaS
| CPaaS | UCaaS | CCaaS | |
|---|---|---|---|
| Stands for | Communications Platform as a Service | Unified Communications as a Service | Contact Center as a Service |
| Primary user | A developer and the application's end users | Employees (desk phone, meetings, chat, presence) | Contact-center agents and supervisors |
| What you buy | APIs, SDKs, phone numbers, usage (minutes, messages) | Hosted PBX + meetings + often messaging, per user/month | ACD/queues, IVR, routing, WEM, supervisor tools, per agent/month |
| Call control | Your code (REST, webhooks, TwiML-like markup, or a voice SDK) | Admin dial plan, ring groups, client app | Skills-based routing, outbound dialer campaigns, QM |
| Typical "phone" | WebRTC in your app, or SIP into your own backend | Vendor softphone / desk phone | Agent desktop (often WebRTC) plus CRM panel |
| PSTN | The CPaaS is usually the originating and terminating carrier (or resells one). BYOC appears in some stacks. | Often included. BYOC optional on some platforms. | Often included. BYOC common for enterprises with existing trunks. |
What a CPaaS actually exposes
- Numbers: DIDs, local, toll-free, sometimes short codes. Voice and 10DLC messaging are provisioned as separate products on the same E.164.
- Voice: outbound create-call APIs, inbound webhooks when a DID is called, conference, transfer, gather DTMF, TTS/STT.
- Media in the browser: WebRTC SDKs so a user talks without a SIP phone.
- SIP: trunks or registration domains for on-prem or custom SBCs (SIP trunking into the platform).
- Messaging: SMS, MMS, A2P / 10DLC registration, toll-free texting.
- Status: CDRs, recording files, message receipts, delivery errors.
Under the API
The HTTP API does not carry the audio. The CPaaS still runs SIP, RTP, and often an SBC farm. Your webhook is application signaling. The caller still occupies a concurrent media path. Call quality (MOS, jitter, 150 ms one-way) still applies. Codec choice on a WebRTC client (Opus) may transcode to G.711 toward the PSTN. That transcoding costs the platform CPU and degrades audio quality.
Identity and compliance stay on you
The platform can sign STIR/SHAKEN as the originating provider if it is that provider. It cannot invent TCPA consent. 10DLC brand and campaign registration still sit with the A2P program. If the softphone you embed amounts to a phone system, E911 becomes an MLTS-style location problem, not just another notification API.
CPaaS vs buying a SIP trunk
| Need | Usually a SIP trunk + PBX | Usually CPaaS |
|---|---|---|
| Employees have extensions and a company directory | Yes | Only if you build that application |
| An app places or receives calls as part of a product (delivery, lending, telehealth) | Awkward | Yes |
| Programmable SMS at application volume | Not a PBX job | Yes, plus 10DLC |
| Keep an existing Avaya / Cisco dial plan, replace the PRI | Yes (SIP trunking) | Only via SIP integration |
Limits that surprise teams
- CPS (calls per second) and message throughput are contract limits; the HTTP API does not remove them.
- Geographic media: a webhook in one region and RTP in another adds latency.
- Number reputation and robocall analytics apply to CPaaS-originated CLI the same as any other OSP.
- Recording and data residency follow the CPaaS region you chose, not the end user's office.