--- title: "The five layers of a communications stack, and which one you are actually shopping for" summary: "Most evaluations compare transport, which is the commodity layer. The four above it are where programmes succeed or fail." canonical: https://cpaas.co/en/insights/the-five-layers kind: explainer depth: foundation origin: original published: 2026-08-10T11:34:07.986Z updated: 2026-09-08T11:34:08.085Z topics: ["Architecture", "CPaaS", "Fundamentals"] language: en --- # The five layers of a communications stack, and which one you are actually shopping for > **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/insights/the-five-layers ## Transport ```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. Issued credentials, scopes, 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. ``` Getting bytes to a handset or an inbox. This is the layer with published per-message pricing, the layer every comparison table compares, and the layer where the differences between serious vendors are smallest. It is a commodity in the precise economic sense: substitutable, price-competitive, and increasingly hard to differentiate. Which is exactly why vendors would rather talk about it than about the layers above, where switching is hard. ## Identity Who is allowed to send what, on whose behalf. Issued credentials, scopes, revocation, and — the part almost nobody has — service-to-service identity, so one system can act for another with proof and a revocation path. Without this layer you can send, but you cannot delegate, cannot revoke a partner's access without rotating everyone's, and cannot answer "who sent this" after the fact. ## Orchestration Deciding what to send, to whom, on which channel, in what order, and what to do when nothing comes back. This is where the actual business logic lives, and where the difference between one message and a programme is made. Skip this layer and every channel becomes its own project, with its own definition of a customer. That is how the same person receives the same notice three times in an hour from three different systems. ## Consent and governance Permission, preference, disclosure and the evidence for all three. It is not a subsection of orchestration — it must be able to veto orchestration, which means it sits above it. ## Measurement Whether any of it worked, in terms someone outside the team recognises. Not delivery rate: outcomes, with a holdout. ## The point of the layering Two things fall out of it. **Your evaluation is probably at the wrong altitude.** If the shortlist is being decided on per-message price, you are optimising the commodity layer while the layers that determine success are unexamined. **Switching cost climbs as you go up.** Transport is genuinely swappable. An orchestration layer holds your logic; a consent ledger holds evidence you are legally obliged to keep. Buy transport casually. Buy the upper layers as though you will live with them for years, because you will. ## How to tell which layer a vendor actually sells Almost every vendor claims all five. A quick way to find the truth: ask what happens at the boundary. **Transport specialists** answer routing questions precisely and orchestration questions vaguely. Ask about branching on a customer's reply and you will get a webhook and a suggestion. **Orchestration specialists** have an opinion about journeys and are indifferent about routes. Ask which carrier a message takes to a given country and the answer is "our partner's". **Suites** claim both, and the honest question is which half was built and which was acquired. Ask whether the two share an identity model. If a contact in the journey builder and a contact in the messaging log are different objects, they were bolted together, and that seam becomes yours. ## The layer that decides your exit Switching cost is not evenly distributed, and knowing where it concentrates changes what you negotiate hardest. Transport is genuinely swappable — a thin abstraction and a fortnight. Orchestration holds your business logic, and moving it means re-expressing every journey in a new tool's idiom. Consent holds evidence you are legally obliged to retain and may need years later. So negotiate export rights hardest on the layers you are least able to leave, which are precisely the ones vendors are least keen to make portable. If a contract lets you export messages but not journeys or consent history, you have bought a one-way door. ## Where identity keeps being skipped Of the five, identity is the one most often absent entirely, and its absence is invisible until it is expensive. Most stacks have credentials for applications and none for delegation — nothing that expresses "this system is acting for that customer, with these permissions, until this moment". It works fine until something is layered on top, and then revocation becomes all-or-nothing and audit becomes archaeology. ## Sequencing a build If you are assembling this rather than buying it, the order that avoids rework is: 1. **Consent first.** Everything else eventually asks it a question, and retrofitting a ledger under a live send path is the worst of the migrations. 2. **Transport second**, behind a thin interface, so it stays replaceable. 3. **Orchestration third**, once you know what your journeys actually are rather than what you imagine they will be. 4. **Measurement fourth**, with the holdout designed in from the first campaign. 5. **Identity when you first delegate** — and not a day later, because retrofitting it means changing every integration at once. ## What to take away - Shortlists are usually decided on the commodity layer while the decisive layers go unexamined. - Ask a vendor a boundary question; the vagueness tells you what they really are. - Switching cost rises as you go up. Negotiate export rights accordingly. - Build consent first and identity before you delegate; both are miserable to retrofit. --- 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.