§01 context
A CRM for gyms and studios wanted their tenants to message leads on WhatsApp without leaving the product. Every tenant was exporting lists into a separate tool and pasting numbers by hand.
We built two services. A public one that only ingests Meta's webhooks, and an internal one that holds every credential and is reachable only from the CRM's backend. Onboarding runs through Meta's Embedded Signup, and each tenant's system user token is encrypted at rest.
§02 shape
How it works
CRM backend (owns auth + tenants)
│ internal network only
▼
WhatsApp API Service ── holds App Secret + per-tenant tokens
│
▼
Meta Cloud API ──── webhooks ────▶ Webhook Service (public)
│ validate + enqueue
▼
RabbitMQ ─▶ Postgres (status, analytics)§03 hard parts
The hard parts
- 01
Leaving auth to the CRM
The CRM already knows its users and tenants, so we didn't build that again. The service trusts whoever calls it, and the network makes sure only the CRM backend can. Less code to get wrong, and another product with its own auth could plug it in the same way.
- 02
Keeping credentials off the internet
The service that sends messages has no public route. The public receiver still needs the App Secret to check webhook signatures, but it doesn't get tenant access tokens or endpoints for sending. It only gets what it needs to receive and verify events.
- 03
No sending until onboarding is done
Embedded Signup gives back a short-lived code. The backend swaps it for a system user token, registers the number, and only then marks the project active. A project that isn't active can't send anything.
stack
- TypeScript
- NestJS
- PostgreSQL
- RabbitMQ
- WhatsApp Cloud API
next →
Compass
A multi-tenant CRM for real-estate sales teams, from tenant provisioning to lead assignment.