CPaaS (Communications Platform as a Service) works by putting an API between your application and the carrier networks that actually deliver a call, a text, or a chat message: your code sends one request, the platform translates it into the signaling a network understands, and it reports back what happened — ringing, delivered, failed — through a webhook your application listens for. Every capability a CPaaS platform ships, from an outbound SMS to an inbound AI voice agent, runs through that same loop: request in, network out, event back. This guide walks through each layer of that architecture, traces one message through it end to end, and shows where Orbit's own implementation fits.
Why an API sits between your app and the phone network
Before CPaaS existed, adding a phone call or a text message to a piece of software meant becoming a telecom operator: leasing lines, negotiating carrier interconnects, and speaking SS7 or SMPP — the signaling protocols carriers use to hand off calls and messages to each other — directly. That was a multi-quarter project for a team whose actual job was building a product, not running a switch.
A CPaaS platform absorbs that complexity once, on behalf of every customer, and exposes it as a small set of HTTP endpoints and SDKs. A developer who has never touched SS7 or SMPP can place a call or send a message with one API request, because the platform already holds the carrier relationships, the compliance registrations, and the routing logic underneath it.
The architecture behind a CPaaS request
A request moving through a CPaaS platform passes through four layers, in the same order, regardless of whether it is a voice call, an SMS, or a WhatsApp message.
The API and SDK layer
This is where your code starts: a REST call, a webhook configuration, or an SDK method — "send this message to this number" or "place a call and connect it to this flow." The API layer authenticates the request, validates it, and hands it to the platform's orchestration engine.
The orchestration layer
Orchestration decides what actually happens with the request: play an IVR menu, run a scripted flow, or hand the call to an AI voice agent that reasons about what the caller says and responds in real time. This is also where no-code flow builders live, so a non-developer can wire a journey without writing the underlying call-control logic by hand.
The channel and network layer
This is where a request becomes a real signal on a real network. For voice, that means terminating the call onto the phone network through carrier interconnects; for SMS, it means handing the message to a carrier or an aggregator for delivery to the handset; for WhatsApp, RCS, and other OTT channels, it means the platform's registered connection to that channel's own business messaging API. How many hops a request takes here — a platform's own direct carrier connections versus a resold aggregator relaying through yet another aggregator — is usually the single biggest factor in delivery speed and reliability.
The event and webhook layer
The network layer's job is not done once a call connects or a message is handed off — the platform has to report back. Delivery receipts, call status changes, recording-ready notifications, and inbound replies all flow back to your application as webhook events, which is what lets your code react to a customer's reply or a failed delivery instead of guessing.
What happens, step by step, when your app sends one SMS
Tracing a single message through the architecture above makes the loop concrete:
- Your application calls the messaging API with a destination number and message body.
- The API layer authenticates the request and checks it against your account's compliance rules — sender registration, opt-out status, and any fraud-screening rules you have set.
- The orchestration layer resolves routing: which channel, which sender ID, and (for omnichannel platforms) whether this destination should get SMS, WhatsApp, or another channel based on your rules.
- The network layer hands the message to a carrier or a direct wholesale route for delivery to the handset.
- The carrier returns a delivery receipt (DLR), which the platform relays back to your application as a webhook — delivered, failed, or undelivered with a reason code.
- If the customer replies, the inbound message arrives back through the same webhook mechanism, landing in your application or a shared inbox rather than disappearing into a carrier's network.
A voice call and an AI voice agent follow the identical shape — request, orchestration, network termination, event callback — with the orchestration layer doing more work: streaming the caller's speech to a model, generating a spoken response, and deciding when to hand off to a human.
The layers, what each one does, and what a weak one costs you
The four request-handling layers above run in order for every call or message. Metering sits alongside them, cross-cutting: it measures usage on all four so it can be rolled into one invoice.
| Architecture layer | What it does | What a weak implementation costs you |
|---|---|---|
| API / SDK layer | Authenticates and validates every request before anything happens | Unclear errors, brittle SDKs, slow integration time |
| Orchestration layer | Runs IVR flows, journeys, and AI voice agents on top of the raw channel | Rigid, code-only flows with no visual builder for non-developers to use |
| Channel & network layer | Terminates the call or hands off the message to a real carrier network | Extra aggregator hops, which show up as added latency, lower answer/delivery rates, and less visibility when something stalls |
| Event & webhook layer | Reports delivery, call status, and inbound replies back to your app | Delayed or missing delivery receipts, silent failures, no way to react to a reply |
| Metering & billing layer | Meters usage per message, minute, and API call and rolls it into one invoice | A separate bill and contract per channel instead of one usage-based account |
How Orbit implements each layer
Orbit's CPaaS puts voice, SMS and MMS, WhatsApp, RCS, email, and embeddable video behind one API and one pay-as-you-go account, so the orchestration layer above — flows, journeys, and AI voice agents — sits on top of every channel rather than being wired separately per channel. Outbound calls terminate over Devotel's own wholesale softswitch, which connects directly to 500+ global carriers, rather than a resold aggregator hop; that is the network-layer difference the table above calls out, and it is also why Orbit's cloud phone system and AI voice agents run on the same terminated path instead of two separate vendors. The numbering and cellular connectivity underneath a deployment — phone numbers, number lookup, eSIM and IoT data plans — is its own layer too, covered under NaaS. See Orbit vs Twilio and Orbit vs Telnyx for how that network layer compares to two of the incumbent CPaaS providers.
Frequently asked questions
What is CPaaS in plain terms?
CPaaS is an API layer that lets your application send a message or place a call without your team building or operating the carrier infrastructure underneath it. You call an API; the platform handles the network, the compliance registrations, and reports back what happened.
How does a CPaaS platform actually send a message or place a call?
Your request passes through four layers in order: an API layer that authenticates it, an orchestration layer that decides what to do with it (a flow, an IVR menu, or an AI agent), a channel and network layer that hands it to a real carrier network, and an event layer that reports the outcome back to your application as a webhook.
Do I need to run my own telecom infrastructure to use CPaaS?
No — that is the entire point of the category. A CPaaS provider holds the carrier interconnects, aggregator relationships, and compliance registrations once, on behalf of every customer, and exposes the result as a small set of API endpoints and SDKs.
How is CPaaS usage billed?
Almost all CPaaS platforms meter usage per message, per minute, or per API call rather than per seat, and roll every channel into one account. Orbit publishes current per-unit rates on its pricing page.
What happens when a customer replies to a message or a call needs to reach a human?
Inbound activity — a reply, a call that needs a live agent, a delivery failure — arrives back through the same webhook mechanism that reports outbound status, which is what lets your application (or a shared team inbox) react to it instead of the event disappearing into the carrier network.
Does the number of network hops actually matter for reliability?
Yes. Every additional hop between a CPaaS platform and the destination handset — an aggregator reselling another aggregator's route, for instance — is another place a call can fail to connect or a message can stall before delivery. A platform with its own direct carrier or wholesale connections generally has fewer places for that to go wrong than one reselling someone else's aggregator relationship.
The takeaway
A CPaaS platform is not one product — it is four layers working in a fixed order: an API that takes your request, orchestration that decides what to do with it, a network layer that turns it into a real call or message, and an event layer that reports back what happened. The quality of a CPaaS provider comes down to how well each layer is built, and in particular how many hops sit between its network layer and the handset. Understanding that architecture is what makes it possible to evaluate a CPaaS platform on substance — API design, orchestration flexibility, network reach, and webhook reliability — rather than on channel-count marketing alone.
Published 17 July 2026.