What are CPaaS APIs, and how do they connect communications to an application?

Each provider names its objects differently, so we'll use Twilio's documentation as the worked reference. Its voice API lists Calls, Recordings, Conferences and Queues as resources under one base URL. Messages and phone numbers are resources too. Your application also handles one credential, the access token, which lets a browser or phone app connect.

A finished product has the same things underneath, and it offers them through an app instead of an API. Atlantech's atlantech|text adds SMS and MMS to Microsoft Teams on the direct-dial number an employee already has. The employee types a text in the Teams desktop or mobile app. The interface is the Teams app, so there is nothing for your code to create or query.

That is the right design for a product people use as delivered. A CPaaS API serves software you're building, whether a person or an event in another system triggers each message. Your code has to send the message and act on the result, which is why the API exposes the message as an object with an ID and a status.

Suppose a pharmacy's prescription system texts a customer when an order is ready. With Twilio, the system sends one POST request to the Messages resource:

curl -X POST "https://api.twilio.com/2010-04-01/Accounts/$ACCOUNT_SID/Messages.json" \
  -u "$API_KEY_SID:$API_KEY_SECRET" \
  --data-urlencode "To=+13015550123" \
  --data-urlencode "From=+12025550147" \
  --data-urlencode "Body=Your prescription is ready for pickup." \
  --data-urlencode "StatusCallback=https://pharmacy.example/sms-status"

The request names a recipient in To, a sender in From and the content in Body. Twilio creates a Message resource and identifies it with a SID, a unique string that starts with SM for a text. The new message begins in the status queued. So a successful response tells you Twilio has accepted the message. It doesn't tell you the customer has received it.

The pharmacy's system should save that SID on the prescription order, because the SID is how it will match later status reports to the order.

Messages are billed by the segment. Twilio's US price list charges $0.0083 per SMS segment, and carriers add their own per-message fees on top, such as $0.0035 for an outbound SMS to AT&T. Retries need some care. If your code repeats a request that Twilio already accepted, Twilio creates a second Message resource.

The -u line in that request is the authentication. Twilio's API uses HTTP Basic authentication, with an API key as the username and the key's secret as the password. Twilio recommends API keys for applications because a key can be revoked. Give each application its own key, and a leaked one can be turned off while the others keep working.

That arrangement works on a server you control. It doesn't work in a browser or a phone app, where a stored key can be copied. For those, Twilio uses access tokens. An access token is a short-lived JSON Web Token that your server creates to vouch for one user, and it lasts at most 24 hours. Twilio's Voice, Video and Conversations client SDKs sign in with it.

Events reach your application as HTTP requests the provider sends to URLs you host. They come in two kinds.

The first kind reports on something you started. The pharmacy's request included a StatusCallback URL, so Twilio posts status updates to that address as the message's status changes. The statuses Twilio documents for an outbound message include queued, sending, sent, delivered, undelivered and failed.

The pharmacy's code should act on the statuses it's told about. It can mark the order as notified when a delivered report arrives, and put the customer on a list for a phone call when the report says undelivered or failed. A delivered status doesn't show that the customer read the text, and the order needs a state for a text that was sent with no delivery report yet. Twilio's webhook guide says informational requests need only a standard 200 OK in reply.

The second kind starts outside your application. In Twilio, a phone number is an IncomingPhoneNumber resource with a voice URL and an SMS URL. Twilio calls the SMS URL when the number receives a text, so a customer's reply to the pharmacy arrives there. An incoming call goes to the voice URL, with one difference. Twilio waits for your response and treats it as instructions for the call, which we cover in how CPaaS handles an incoming call.

Both kinds of URL sit on the public internet, so your code should confirm that each request came from the provider. Twilio signs its requests with an X-Twilio-Signature header and recommends checking it with the validation method in its SDK.

Numbers are objects as well, so setup can be code too. A POST to Twilio's IncomingPhoneNumbers list provisions a new number, and the same resource holds its voice and SMS URLs. An application that gives each store its own number can do that from its own setup screen. US texting from a 10-digit number also needs carrier registration, which Twilio's 10DLC documentation describes.

The rest is ordinary application work. Your database needs a place for the provider's ID on each record that triggers a message. Your server needs endpoints for status reports and inbound traffic, plus code for each status the business cares about.

The work continues after launch, and part of it is outside your control, because a provider can withdraw an API. Microsoft announced on September 23, 2026 that it is retiring Azure Communication Services as a standalone offering on September 30, 2028, with its SMS, email and chat services among those retired. An application built on those APIs has about two years to move to another provider. The move is smaller when the provider's requests and callbacks sit behind one module of your code, and your own database holds the customer records and message history.