How we build: one contact model, two channels, no glue code
The architectural decision behind RapidRoot — why messaging and voice share a data model instead of integrating after the fact.
RapidRoot Engineering20 Jun 2026 7 min
In short
RapidRoot is built around a single contact and conversation model that both Messaging Cloud and Voice Cloud read and write. Channels are adapters on top of that shared core, which is why history, reporting and automation behave consistently rather than needing synchronisation between separate products.
- One conversation model, many channel adapters.
- Integrating two separate products after the fact produces sync bugs that never fully go away.
- Shared identity is what makes cross-channel reporting possible at all.
The decision
The easy path is to build a WhatsApp product, then build a voice product, then integrate them. It ships faster and it produces an integration surface you maintain forever: two identity systems, two definitions of a conversation, two reporting pipelines that disagree.
We chose the slower path — a shared core with channel adapters — because the thing customers actually want is one view of a customer, and that is not something you can bolt on later.
The shape of it
Contacts & identity
One record per customer
Conversation core
Threads, ownership, status, history
Channel adapters
WhatsApp and telephony providers
Surfaces
Inbox, campaigns, voice agents, analytics
What it costs
- Every new channel has to fit the shared model, which slows the first version of that channel.
- Core changes touch everything, so the test surface is larger.
- In exchange: no sync jobs, no duplicate contacts, one place to reason about permissions.