The term has no specification behind it. The definitions in circulation come from analyst firms and from vendors, as part of market categories they maintain. Several of those glossaries are not publicly readable.
What does the label actually name?
A specific piece of work you would otherwise do yourself.
Without a provider, sending SMS at scale is four jobs:
- Carrier contracts and connections in each market.
- Number supply and its registration paperwork.
- Per-country rules about what may be sent and by whom.
- The operations that keep delivery working.
With a provider, it is an HTTP request.
The same shape repeats per channel. WhatsApp and RCS have platform owners rather than carriers, so the work becomes approvals, template review and business verification. The position is identical: somebody holds the relationship and exposes it as an API.
How would I evaluate one?
By what it absorbs, since the API is the easy part.
Five questions, each with a checkable answer:
- Where does the number come from, and who registers it? Buying a number is easy. Getting it approved to send in a given country is the work. A provider that hands that back leaves the hard part with you.
- What happens when a channel changes its rules? Channel policies move. Either the provider absorbs the change, or it arrives as your incident.
- Is the failure detail useful? A delivery failure reported only as failed cannot be acted on. One that names a cause can. Bird's SMS filtering page sets out what carriers do and do not report back.
- Is the interface documented as a contract? A published OpenAPI spec is a different commitment from a documentation site.
- Is pricing per country visible before you commit? Message pricing differs by destination. Rates you cannot see until you are a customer cannot be compared against anyone else's.
Is CPaaS the same as omnichannel?
No. They answer different questions. A product can satisfy one without the other.
CPaaS is about who runs the telecom. Omnichannel is about whether your channels share state. A provider can expose six channels through one API while each keeps its own contact list and its own consent record. That satisfies the first and not the second. Omnichannel vs multichannel covers how to test the second claim.
The neighboring acronyms, CCaaS and UCaaS, name contact-center and internal-communications products rather than developer APIs. They share the as-a-service suffix and little else.
Where does Bird stand on it?
Against the pricing model rather than against the capability.
Bird publishes that position under the title "The end of CPaaS". The claim inside is narrower than the title. Bird's argument is that messaging has commoditized and its margins are heading to zero. What ends, on that argument, is the pricing practice that rests on buyers being unable to compare rates across countries and carriers. The argument does not say the capability is going away.
That argument has a checkable form: whether a provider's per-country rates are visible before you sign. Bird's own rates are published per country on the pricing pages rather than quoted on request.
简而言之
It is a market label, not a specification.
No standards body defines it, so the boundary of the category is drawn by whoever is describing it.
What it names is real enough.
Reaching carrier and platform networks through an HTTP API, without contracts, connections or compliance machinery of your own.
What matters is what the provider absorbs.
Routes, number supply, sender registration and channel rules are the work. An API that leaves those to you has not removed much.
Bird argues the pricing model behind the category is ending.
Not the capability. The claim is about margins on commoditized messaging. It is a position rather than a definition.