The CPaaS Company

The Ecosystem

One directory for the whole category. Every provider is assessed against the same six published criteria, ours included — and where a listing is ours or is sponsored, the card says so.

A2P Network

a2p.network

VerifiedOur productFeatured

One API and one console for every business messaging channel, with scoped keys, quotas, health and signed callbacks.

CPaaS · Global

SMS
WhatsApp
Telegram
Email
Messenger
Instagram
WeChat

Visit site

The programmable edge of the group. The only product here whose customer is a system rather than a person.

Built for

Developers and technical operators who want to integrate once and reach every channel.

Seven messaging channels behind one send-and-receive interface, wrapped in the things an integrator actually needs: issued credentials, a published specification, delivery callbacks and per-channel health.

Scoped API keys. A key can be restricted to a subset of channels, so a partner integration never gains more reach than it was granted.
Signed outbound webhooks. Delivery events are posted with an HMAC-SHA256 signature, filtered per user, channel and event type.
Live channel health. Each provider is probed continuously and the results drive a public status page.

Capabilities

Scoped, revocable API keys with per-channel quotas
HMAC-signed delivery webhooks
OpenAPI description and a public status page
TOTP multi-factor authentication with backup codes

Assessment

Assessment
Operational transparency	Met	Public status page driven by live probes rather than manual updates.
Documented interfaces	Met	OpenAPI description published; a developer can integrate without a sales call.
Delivery accountability	Met	Per-message delivery events with cause codes, dispatched as signed webhooks.
Consent and compliance	Not assessed	Consent is handled by the calling system, not the transport. Assessment pending.
Data handling	Not assessed	Not yet worked through.
Commercial clarity	Not met	No published pricing. Quoted per deployment.

How it interoperates

A2P Network is the published edge. It holds the three things the other four lack: issued and revocable credentials, an OpenAPI description, and a signed webhook dispatcher.

The direction of travel is for it to delegate rather than duplicate — keeping its keys, scopes, specification and health probes, and calling the other products rather than sending directly.

Omnichannel Systems

omnichannel.systems

VerifiedOur product

Inbound conversations become tickets and appointments, routed by rules and measured against service-level targets.

Customer operations · Global

WhatsApp
Telegram
Email
SMS
Messenger
Instagram
Web

Visit site

The operational centre of the group: the only product here that models work rather than messages.

Built for

Support and operations teams who live in a queue all day.

An agent inbox over eight channels, with the machinery a real support function needs behind it: ticket lifecycles, appointment booking, rules-based routing, and service-level measurement that distinguishes first response from resolution.

Its richest asset is an internal event bus — every state change in a conversation is an event — which nothing outside the product can currently subscribe to.

Capabilities

Agent inbox with ticket lifecycles and assignment
Appointment booking tied to the conversation
Rules-based routing and escalation
Service-level measurement separating response from resolution

Assessment

Assessment
Operational transparency	Not assessed	Not yet worked through.
Documented interfaces	Not met	A generic HTTP channel exists, but there is no published specification for it yet.
Delivery accountability	Met	Every conversation state change is an event with a cause, retained and queryable.
Consent and compliance	Not assessed	Not yet worked through.
Data handling	Not assessed	Not yet worked through.
Commercial clarity	Not met	No published pricing.

Unified CX

unified.cx

VerifiedOur product

A visual journey engine over twelve channel adapters, with a contact graph that tracks lifecycle, consent and engagement.

Journey orchestration · Global

WhatsApp
Telegram
Email
SMS
Web
Voice

Visit site

The strongest domain model in the group — and the one that quietly built most of what the API layer was meant to become.

Built for

Marketing and CX teams designing multi-step journeys rather than single sends.

A journey is a graph, not a sequence: branches on behaviour, waits on time or event, and a contact record that carries consent state per channel rather than one global flag.

The adapter layer is the part worth stealing. Twelve channels sit behind one interface, including a generic HTTP adapter that can call anything that speaks JSON — which is why federating with it needs no new integration primitive.

Capabilities

Visual journey builder with behavioural branching
Per-channel consent on the contact record
Twelve channel adapters behind one interface
Generic HTTP adapter for anything that speaks JSON

Assessment

Assessment
Operational transparency	Not assessed	Not yet worked through.
Documented interfaces	Met	Adapter interface is documented internally and stable enough to build against.
Delivery accountability	Met	Per-step outcomes recorded against the contact, not just the send.
Consent and compliance	Met	Consent is modelled per channel and enforced at the adapter, not left to the caller.
Data handling	Not assessed	Not yet worked through.
Commercial clarity	Not met	No published pricing.

iCall

icall.tel

VerifiedOur product

Self-hostable video meetings with three interchangeable backends, including a path that needs no video vendor at all.

Video · Global

WebRTC video
LiveKit
GetStream
Email

Visit site

The only product here whose defining feature is what it can be detached from.

Built for

Teams that need meetings inside their own product, and cannot or will not send media through a third party.

Three backends behind one interface: a managed provider, self-hosted LiveKit, and a direct peer-to-peer path built on the browser's own WebRTC APIs.

The third option is the point. For small meetings it removes the media vendor from the architecture entirely, which changes both the cost curve and the data-residency conversation.

Capabilities

Three interchangeable media backends
Peer-to-peer path with no media vendor
Self-hostable end to end

Assessment

Assessment
Operational transparency	Not assessed	Not yet worked through.
Documented interfaces	Not met	Not yet programmable from outside; making it integratable is on the roadmap.
Delivery accountability	Not assessed	Call quality metrics exist per session but are not exposed.
Consent and compliance	Not assessed	Not yet worked through.
Data handling	Met	The peer-to-peer path keeps media off any vendor's infrastructure, which is verifiable by inspection.
Commercial clarity	Not met	No published pricing.

LiveKit

livekit.io

Verified

Open-source WebRTC infrastructure, self-hostable or managed. Used as one of iCall's backends.

Real-time media · Global

WebRTC
Realtime media

Visit site

The clearest example in this directory of what an open-source dependency does to a buyer's leverage.

Disclosed relationship: one of our own products, iCall, uses LiveKit as an optional backend. That is why it appears here, and it is why the disclosure is on the card rather than in a footnote.

It is marked verified because every criterion below can be checked against a public repository and public documentation without asking anyone for anything — which is exactly the property the criteria are trying to reward.

Assessment

Assessment
Operational transparency	Met	Source is public; issues and incidents are visible in the open.
Documented interfaces	Met	Documented SDKs and server APIs, all publicly readable.
Delivery accountability	Met	Session and track-level quality metrics exposed to the application.
Consent and compliance	Not assessed	Out of scope: it carries media, it does not decide who may be contacted.
Data handling	Met	Self-hosting means media residency is the operator's choice, verifiable by deployment.
Commercial clarity	Met	Cloud pricing published; self-hosting is free.

Ecosystem

How the directory is assessed

Three listing states are used, and the difference between them is what has been checked — never how much we like the organisation.

Verified. Assessed against all six criteria below, with the evidence recorded.

Listed. Included because it is materially relevant to the category, but not yet assessed. A listing is not an endorsement.

Under review. An assessment is in progress, or a previously verified listing has raised a question that has not been resolved.

The six criteria

Operational transparency. Is there a public status page, and does it reflect real incidents — including partial degradation, not only total outages?
Documented interfaces. Is there a published specification a developer can integrate against without a sales call?
Delivery accountability. Are failures reported with a cause, and is there a defined retry and escalation path?
Consent and compliance posture. Is opt-out handled at the platform level, and is consent tracked per channel rather than as a single flag?
Data handling. Are storage locations, retention periods and sub-processors documented?
Commercial clarity. Is pricing published, or at least explained without obligation?

On "not assessed"

Most listings have several criteria marked not assessed, including large and reputable companies. That is the honest state: some of these questions can only be answered by working through documentation we have not yet worked through, and marking a criterion met on reputation would make the whole scorecard decorative.

Not assessed is not a failure. It is an admission that we have not checked, which is more useful to you than a guess.

On our own products

They are assessed against the same six criteria and marked as ours. One currently sits under review rather than verified, on the delivery criterion: its transport reaches WhatsApp through an unofficial protocol implementation, which is disclosed on its card and discussed at length in our own writing.

A directory that exempted its publisher's products would not be worth consulting.