How does CPaaS work?

CPaaS stands for communications platform as a service. Twilio's CPaaS guide describes it as embedding communication channels in your own application through APIs, SDKs and documentation, in place of a separate communications app. Twilio exposes calls, messages and phone numbers as resources your code creates and manages with HTTPS requests. A request to its phone number resource provisions a new number. Its client SDKs add voice, video and chat inside your app.

So the provider runs the numbers, the carrier connections and the infrastructure behind each channel. Your side is ordinary web development. You need code that makes requests, and a web address where the provider can reach you.

An outbound message starts as an authenticated HTTPS request from your server. Twilio's API documentation uses HTTP Basic authentication, with an API key as the username and the key's secret as the password. The request names the destination number and the content. You can write that request by hand or use the provider's SDK for your programming language, which wraps the same call.

Twilio recommends API keys for applications because a key can be revoked. If each application has its own key and one leaks, you turn that key off without disturbing the others.

Apps that run in a browser or on a phone need a different arrangement, since an account key stored on a customer's device can be copied. Twilio's client SDKs authenticate with a short-lived access token that your server issues.

Inbound traffic is where CPaaS differs most from an ordinary API. The provider has no way to know what your business wants to do with a call, so it asks.

Twilio's voice documentation lays out its version of the sequence. Each phone number has a URL configured on it. When a call arrives, Twilio sends a request to that URL and carries out the instructions it gets back. Those instructions are written in TwiML, an XML format with verbs such as Say, Play, Dial and Record.

In Twilio's format, a reply can be this short:

<Response>
  <Say>Thanks for calling. Connecting you now.</Say>
  <Dial>+13015550123</Dial>
</Response>

Twilio reads the greeting aloud and then connects the caller to that number. Your server made that choice as the call came in, so it could have looked up the caller first and sent a regular customer somewhere else. The callback design exists so each call can run through logic you wrote.

That URL sits on the public internet, so anyone who finds it could send it fake call events. Twilio signs each request with an X-Twilio-Signature header. Your code should check that signature before it responds, and Twilio recommends using the validation method in its SDK over writing your own.

In this Twilio setup, the provider supplies the numbers and carrier connections, so your application can provision a number through an API call.

US text messaging has one more step before traffic flows. Twilio's 10DLC documentation says anyone sending SMS or MMS from an application to US recipients over a standard 10-digit number must register. Registration has two parts. The brand tells carriers who is sending. The campaign describes what the messages are for and how recipients opt in, opt out and get help.

Carriers treat all traffic from a messaging provider as application traffic, so the rule covers even a hobby project. Twilio says registered traffic gets less filtering and higher throughput.

The main charges count traffic. Twilio's US price list charges $0.0083 per SMS segment, sent or received. A segment holds up to 160 standard characters, and fewer when a message is split into parts or uses emoji or other non-standard characters. An outbound MMS costs $0.022.

Carriers add their own per-message fees, which appear on the bill separately. Twilio's examples are $0.0035 for an outbound SMS to AT&T and $0.0045 to T-Mobile. Twilio also rents each phone number by the month, and 10DLC registration carries its own fees.

Suppose a clinic sends 4,000 appointment reminders a month and each one is a single billable segment. The base charge is 4,000 × $0.0083, or $33.20. If every recipient were on AT&T or T-Mobile, carrier fees would add between $14 and $18. That brings message and carrier charges to between $47.20 and $51.20 a month, before number rental and registration fees.

In that example the message bill is about $50 a month. The build asks for more: code that sends each reminder, an endpoint that receives replies, a signature check, carrier registration, and a developer to keep it all running. That balance belongs to this example, and a sender with far higher volume would see a different one.

The alternative is to buy texting finished. Atlantech's atlantech|text puts SMS and MMS inside Microsoft Teams on the direct-dial number an employee already has. Atlantech runs the messaging through its own session border controllers, and employees text from the Teams desktop or mobile app. There's no API to call and no server to host. The price is set per number, starting at $10 per number per month.

A finished service is a texting workflow that's already built. For the clinic, it would give front-desk staff a way to text patients themselves, without a build. The automated reminders are a separate job. CPaaS is for a messaging workflow you need to design yourself, whoever or whatever triggers each message. If the clinic builds its reminders that way, it takes on the endpoint, the registration and the upkeep described above.