What CPaaS actually is, and what it is not

CPaaS — Communications Platform as a Service — is a cloud service that lets your software send and receive text messages, calls and video by calling an API (a documented web address your code can talk to), and pay per use.

A concrete example: a clinic's booking system wants to text patients a reminder the day before an appointment. With CPaaS, a developer adds a few lines that call the provider's API with a phone number and the text. The provider gets the message to the patient's phone and reports back what happened. The clinic never signs anything with a mobile operator.

Before CPaaS, adding a text message to your software meant a commercial negotiation with a telecoms operator, a leased connection, and a protocol designed in the 1990s for bulk messaging between data centres. That took months, not minutes, and was out of reach for most businesses.

CPaaS absorbs the operator relationships, the protocols and the day-to-day operations. What you get instead is an API, documentation and a bill. That is the whole idea; everything else is detail.

A CPaaS is a service that lets software send and receive messages, calls or video through channels it does not own, using credentials it issues, with delivery reported back as data.

• Channels it does not own. The platform is an intermediary between you and mobile operators, Meta (for WhatsApp), Google (for RCS) and so on. Its quality is largely the quality of those relationships.
• Credentials it issues. You get an API key that can be limited to certain actions and revoked. That is what makes it a platform rather than a bulk-send tool.
• Delivery reported back as data. Not just a dashboard: a webhook (an automatic message from the provider to your system) saying "delivered", "failed because the number does not exist", "read". Your system can act on it — for example, by trying email when a text fails.

The category is easiest to see by contrast.

Above all, CPaaS is not a guarantee of delivery. A platform can accept your message and still see it dropped several hops later by an operator's spam filter it will never describe. Keep three words apart:

A dashboard that only shows the first two can look healthy while the programme fails. See delivery rate is not a result.

Many companies put an API in front of someone else's platform. That is legitimate, but you should know which one you are buying from. Ask:

1. Can I integrate without talking to a salesperson? Published documentation, self-service keys and a test environment are cheap to provide and very revealing.
2. What happens when a message fails? A platform that owns more of the path returns a specific cause. A reseller often returns "failed", because it does not know either.
3. What share of the price is the operator's fee? Providers that own more of the route can usually answer. Ones that cannot may be passing on someone else's margin plus their own.

For a message that crosses an operator's network, a large share of the price is a fee the platform collects and passes on. What the platform keeps is the difference, plus whatever it charges for the software around the message.

Two consequences:

• A very low unit price can signal a route the provider does not control — a cheaper, less reliable path. That is a delivery decision presented as a discount.
• The real differences sit above the transport: routing, fallbacks, analytics, consent handling, support. Price those parts explicitly when you compare offers.

The buyer and the daily user are often different people, and products are designed for whoever the vendor's sales team reaches. A platform sold to developers has detailed docs, a test environment and precise error codes. One sold to marketing teams has a campaign builder and a dashboard. Both may send the same message down the same route.

Before shortlisting, decide which of the two you are, and make sure the people who will use the product every day are part of the evaluation.

A provider's public status page is a cheap signal of operational maturity. Look for:

• Granularity — status per channel and per country, not one green light for "Messaging".
• History — past incidents kept visible, with timelines and causes.
• Honesty — partial slowdowns reported, not only total outages.

A page with no incidents in two years usually means less disclosure, not more reliability.

• A2P, P2A, P2P: why the direction of a message matters — the next step in this track.
• The five layers of a communications stack — which part you are really buying.
• Channels are not interchangeable — SMS, WhatsApp, RCS and email compared.
• How to choose a CPaaS provider — when you are ready to shortlist.