A WhatsApp inbox, flow builder and commerce platform, built as a multi-tenant product
whatatalk
whatatalk turns Meta’s raw WhatsApp Business Cloud API into a product: a unified inbox, a no-code flow builder, catalog and order handling, template and campaign management, and the multi-tenant packaging needed to run it as SaaS.
15 flow node types
- Channel
- WhatsApp Cloud API
- Services
- Independent microservices
- Events
- Kafka, RabbitMQ
- Identity
- Keycloak, multi-tenant
Every conversation, customer and automation in one place.
A conversation, its context and its next step.
Messages, translation, quick replies and an AI summary sit beside the contact’s tags, assigned agents and attributes.
A messaging API is not a product.
Turning the Cloud API into something a team can use meant building everything around it.
No working surface
No inbox, contact management or campaign tooling comes with the API.
Logic needs code
Every business rule would otherwise need an engineer.
Concurrent messages
Near-simultaneous messages from one customer must not corrupt state.
Many businesses
Separate data, plans and permissions per client on one platform.
Automate, sell and broadcast from one workspace.
The agent workspace brings the flow builder, catalog, templates and campaigns together with the live inbox.
Visual flow builder
Design conversation flows by connecting nodes, from keyword triggers to API calls and human hand-off.
- Triggerskeyword, first message, button
- Logicconditions + API calls
- Reusenested sub-flows
Catalog and inventory
Manage products, collections and stock, then sync them with Meta’s commerce graph.
- Synclocal-first with Meta
- Bulkimport jobs with row errors
- Orderscatalog, order, payment link
Dynamic interactive templates
Create personalised template messages with product carousels and call-to-action buttons, tracked through Meta approval.
- Typesmedia, carousel, coupon, offer
- Approvalstatus synced automatically
- Personalisecontact variables
Broadcast groups
Send to segmented audiences now or on a schedule, with delivery reporting after the send.
- Audiencessegmented groups
- Timingscheduled sends
- Reportingdelivery level
Architecture
Database-per-service microservices, event-driven where it should be and synchronous where it must be, with each decision answering one specific risk.
Decision 01
A slow flow must never block WhatsApp’s webhook delivery.
Verify the webhook signature, publish a normalised event and return immediately. The messaging service persists the message and emits a flow-trigger event; the flow engine consumes it on virtual threads and takes a per-contact Redis lock so two near-simultaneous messages cannot corrupt session state.
Architecture Narrative
Meta delivers an event to the webhook server, which publishes it to a Kafka queue. The messaging service consumes it and passes it to the flow engine, which takes a Redis lock for the contact before running.
Decision 02
One platform had to serve many businesses with different plans.
Architecture Narrative
Requests enter through the API gateway and Keycloak tenant-aware authentication, then reach services whose queries are scoped by business id. Feature and quota checks go to a central entitlement service holding plans, overrides and quota counters.
Scope every entity and every query by a tenant key, authenticate through a tenant-aware identity layer, and centralise feature gating and quota enforcement in one entitlement service so a plan change takes effect everywhere at once.
Decision 03
Catalog reads should not depend on Meta’s availability or rate limits.
Build the catalog service local-first: writes land in its own store, then sync to Meta as tracked import jobs with per-row status and errors, so a large update neither fails silently nor as one all-or-nothing transaction.
Architecture Narrative
A catalog edit is written to a local MySQL store first. An import job with per-row status then syncs it to the Meta Graph API, and the catalog is assigned to one or more WhatsApp Business Accounts.
What the platform makes possible.
Flow building blocks
Messaging, logic, support and commerce nodes cover common conversations.
Flows start in seven ways
Keyword, first message, button reply, API, sub-flow, catalog order and catch-all.
Browse, order and pay in one chat
Catalog, order and payment-link nodes remove the need for a separate checkout.
Plans, quotas and overrides per business
Different clients can have different capabilities turned on.
Every tenant’s data stays separate
All queries are scoped by business id.
One conversation, end to end
Distributed tracing follows a message from webhook to outbound send.
The right language for each service.
Typed Java for business-heavy services, Node.js for I/O-bound messaging work.
Core services
Flow engine, catalog, entitlement and application core.
Messaging and onboarding
I/O-bound services close to Meta’s API.
Data and events
Per-service storage, queues and locking.
Experience and operations
Agent workspace, identity and observability.