Why n8n should never talk directly to the client system: a WhatsApp self-service architecture

This is a technical case of our own — an architecture demo, not a system delivered to a real client. It exists to show how we structure WhatsApp self-service automation when the project needs to be secure and auditable, not merely work in the demo.

The problem this solves

Companies with a high volume of repetitive requests — internet providers, clinics, residential buildings, e-commerce, service firms — receive the same type of request hundreds of times a month. Change a password, confirm an appointment, check a status, update a record. Each of those requests goes through a human agent today.

Automating this is tempting and easy to get wrong. The fast path is to build the whole flow inside a visual tool and let it call the company system directly.

The common mistake

The flow orchestration tool is excellent for conversation: interactive menus, branching, data collection, session timeout. It is terrible as the place where ERP credentials live.

When the visual flow calls the client system directly, every HTTP request node starts carrying production credentials. There is no real access control, no layer deciding what is permitted, and anyone with access to the flow editor effectively has access to the production system. It is the most common mistake in this kind of automation.

The flow tool never talks directly to the client system. It only talks to the backend, which decides what is permitted.

The architecture

The design deliberately separates the two responsibilities. The orchestration layer handles the conversation. The backend handles what requires security and real logic: identity validation, business rules, idempotency, audit logging and the final call into the client system — ERP, CRM or database.

The full path is: customer on WhatsApp → WhatsApp Cloud API → orchestration layer → validation and execution backend → client system. Orchestration talks only to the backend, over an internal network. No production credential ever circulates inside the visual flow.

The demonstrated flow

Six steps, generic and adaptable to any niche: the customer starts the conversation; the flow presents an interactive menu; the backend validates identity against the client database; the flow collects the request-specific data; the backend executes the action through an API in the client system; and the flow confirms completion.

What changes from one niche to another is only the fifth step. At an internet provider, it is a router password change. At a clinic, confirming or rescheduling an appointment. At a residential building, authorizing a visitor. At an e-commerce store, checking order status. The architecture stays the same.

Implementation decisions

Meta's official WhatsApp Cloud API, not an unofficial library — running service automation on an unofficial library risks getting the number blocked, and that is the kind of saving that turns expensive.

The backend exposes identity validation and request creation, with DTOs validated at the entry point. Every request generates a unique reference number. A malformed identity is rejected at the door; a well-formed identity not found in the database returns an explicit negative, which in the flow triggers handoff to a human agent — rather than freezing the conversation.

The backend image is multi-stage, with a lean runtime, a non-root user and a healthcheck. The environment comes up through composition with the orchestration layer and a reverse proxy with automatic HTTPS.

What is deliberately left out

Real integration with a specific ERP is not part of the demo. That is always the unique part of each project and depends entirely on the client system. What the demo proves is the reusable part: the orchestration architecture and the security boundary between conversation and execution.

Stack

WhatsApp Cloud API · n8n (self-hosted) · NestJS · TypeScript · PostgreSQL · Docker · Caddy