---
title: "The five layers of a communications stack, and which one you are actually shopping for"
summary: "Most evaluations compare transport — getting a message to a phone — which is the commodity layer. The four layers above it are where programmes succeed or fail, and where switching gets expensive."
canonical: https://cpaas.co/en/learn/the-five-layers
kind: explainer
depth: foundation
origin: original
published: 2026-09-15T16:26:18.899Z
updated: 2026-10-14T16:26:19.446Z
topics: ["Architecture", "CPaaS", "Fundamentals"]
language: en
---
# The five layers of a communications stack, and which one you are actually shopping for

A **communications stack** is everything between "we should tell the customer" and "it worked". It helps to see it as five layers, because buyers usually compare only the bottom one.

Take a chain of dental clinics sending appointment reminders:

- **Transport** gets the text to the patient's phone.
- **Identity** decides that the downtown branch may send under the clinic's name, and the marketing agency may not.
- **Orchestration** sends a reminder 24 hours before, and a WhatsApp message if there is no reply by evening.
- **Consent and governance** checks that this patient agreed to reminders on this channel.
- **Measurement** shows whether no-shows actually fell, compared with patients who received nothing.

> **Interactive figure — stack-builder.** Switch a layer off and read what stops working. Then notice which layer every vendor demo spends its time on.
> Available at https://cpaas.co/en/learn/the-five-layers

```diagram:layers
# The stack, bottom to top
Transport | Bytes to a handset or an inbox. The commodity layer, and the one every comparison table compares.
Identity | Who may send what, on whose behalf. Credentials, permissions, revocation, delegation.
Orchestration | What to send, to whom, on which channel, and what to do about silence. Your business logic.
Consent and governance | Permission, preference, disclosure and the evidence for all three. Must be able to veto the layer below.
Measurement | Whether any of it worked, in terms someone outside the team recognises.
> Switching cost climbs as you go up. Transport is genuinely swappable; the layers above hold your logic and your evidence.
```

## The five layers in brief

| Layer | Question it answers | What goes wrong without it | How hard to switch |
|---|---|---|---|
| Transport | Can we reach this phone or inbox? | Nothing arrives | Easy |
| Identity | Who is allowed to send what, for whom? | You cannot revoke one partner without rotating everyone's keys | Medium |
| Orchestration | What, when, which channel, and what if no reply? | The same person gets the same notice three times from three systems | Hard |
| Consent and governance | Are we allowed, and can we prove it? | Complaints, fines, a channel taken away | Hard, and records must be kept |
| Measurement | Did it change anything? | You report delivery rates and guess the rest | Medium |

## Transport

Getting bytes to a handset or an inbox. This layer has published per-message prices, appears in every comparison table, and is where differences between serious providers are smallest. It is a **commodity** in the economic sense: substitutable and price-competitive. That is exactly why vendors like to talk about it — the layers above are where switching is hard.

## Identity

Who may send what, on whose behalf: API keys, scoped permissions, revocation and — the part most stacks lack — **delegation**, so one system can act for another with proof and a way to revoke it. Without it you can send, but you cannot answer "who sent this?" after the fact, or cut off one partner without disrupting everyone.

## Orchestration

Deciding what to send, to whom, on which channel, in what order, and what to do when nothing comes back. This is where your business logic lives, and where one message becomes a programme. Skip it and every channel becomes its own project with its own definition of a customer.

## Consent and governance

Permission, preference, disclosure (for example, telling people when they are talking to an AI) and the evidence for all three. It is not a sub-feature of orchestration: it must be able to **veto** a send, which is why it sits above. See [consent is a data model](/en/learn/consent-is-a-data-model).

## Measurement

Whether any of it worked, in terms someone outside the team recognises. Not delivery rate — outcomes, compared with a group that received nothing. See [delivery rate is not a result](/en/learn/delivery-rate-is-not-a-result).

## Why the layering matters

**Your evaluation is probably at the wrong altitude.** If the shortlist is decided on per-message price, you are optimising the commodity layer and leaving the decisive ones unexamined.

**Switching cost climbs as you go up.** Transport can be swapped behind a thin interface in weeks. Orchestration holds your logic; moving it means rebuilding every journey in a new tool. Consent holds evidence you may be legally required to keep for years. Buy transport casually; buy the upper layers as if you will live with them for years, because you will.

```diagram:scale
# How hard each layer is to leave
Swapped in weeks | Lived with for years
Transport | 1 | Easy: swappable behind a thin interface
Identity | 5 | Medium
Measurement | 5 | Medium
Orchestration | 9 | Hard: it holds your logic, and moving it rebuilds every journey
Consent and governance | 9 | Hard, and the records must be kept
> Buy transport casually; buy the upper layers as if you will live with them for years.
```

## How to tell which layer a vendor really sells

Almost every vendor claims all five. Ask questions at the boundaries:

- **Transport specialists** answer routing questions precisely and orchestration questions vaguely. Ask how a journey branches on a customer's reply and you get "send us a webhook".
- **Orchestration specialists** have strong views on journeys and vague ones on routes. Ask which operator carries a message to a given country and the answer is "our partner's".
- **Suites** claim both. Ask whether the journey builder and the messaging log share one customer record. If they are different objects, the products were joined after the fact, and that seam becomes your problem.

None of these is wrong to buy. The point is to know which layers you are getting, and plan for the rest.

```diagram:compare
| Ask them | The tell
Transport specialists | How does a journey branch on a customer's reply? | "Send us a webhook"
Orchestration specialists | Which operator carries a message to this country? | "Our partner's"
Suites | Do the journey builder and the messaging log share one customer record? | If they are different objects, the seam becomes your problem
```

## The layer that decides your exit

Negotiate export rights hardest on the layers you are least able to leave — orchestration and consent — which are often the ones vendors are least keen to make portable. A contract that lets you export message logs but not journeys or consent history is a one-way door.

## If you are building rather than buying

An order that avoids rework:

1. **Consent first.** Everything else eventually asks it a question, and retrofitting a consent ledger under a live send path is the worst migration of all.
2. **Transport second**, behind a thin interface so it stays replaceable.
3. **Orchestration third**, once you know what your journeys actually are.
4. **Measurement fourth**, with a holdout group designed in from the first campaign.
5. **Identity and delegation as soon as a second system or partner sends on your behalf** — retrofitting it later means changing every integration at once.

```diagram:steps
# A build order that avoids rework
Consent first | Everything else eventually asks it a question
Transport | Behind a thin interface, so it stays replaceable
Orchestration | Once you know what your journeys actually are
Measurement | With a holdout group from the first campaign
Identity and delegation | As soon as a second system or partner sends on your behalf
```

## What to ask a provider

- Which of these five layers do you build yourselves, which do you partner for, and which do you leave to me?
- Can I export journeys, templates and consent history in a documented format?
- Can I give a partner limited sending rights and revoke them without affecting anyone else?

## Where to go next

- [Delivery rate is not a result](/en/learn/delivery-rate-is-not-a-result) — the next step in this track.
- [How to choose a CPaaS provider](/en/learn/how-to-choose-a-cpaas-provider) — putting the layers to work in a shortlist.
- [When to build messaging infrastructure](/en/learn/when-to-build-messaging-infrastructure) — the build-or-buy decision.

---

Published by the company behind five products in this category. Those products appear in this site's directory alongside competitors under the same published criteria and are labelled as its own. Editorial content does not recommend them.