WhatsApp API for agencies that automate many clients

The problem when you run WhatsApp for ten clients

At first, every new client gets solved however works: a phone in the office drawer, an instance of a self-hosted tool on a small server, a borrowed number to test the workflow. It works until the fifth client. From there, the familiar symptoms show up:

• The client calls saying the bot stopped and you find out the phone disconnected two days ago.
• One number got blocked and, the same week, two others on the same server started failing.
• Nobody knows what each client's WhatsApp really costs, so the retainer is a guess.
• Every n8n workflow has a different credential, set up by hand, with no standard.

None of these are automation problems. They're infrastructure problems, and infrastructure isn't what your client pays for. They pay for the workflow that qualifies leads, books visits or sends payment reminders. A managed WhatsApp API takes off the agency's plate the part nobody sees and that takes the most work.

One connection per client, each in its own lane

The model that scales for agencies is simple: each client has its own connection, with a predictable name and its own webhook. Never mix two clients on the same number or in the same process.

On D-API, each connection runs in an isolated environment, with its own credentials, its own webhook and a dedicated proxy with a unique IP managed by the platform. When a client's number gets blocked because of a poorly planned campaign, the others keep working. To understand what usually leads to blocks, and how to keep clients from making those mistakes, read how to avoid bans.

Onboarding a new client

Ideally, getting a client live becomes a ten-minute routine, the same for everyone. A plan that works well:

1. Pick the identifier. Use the client name as the sessionId, for example client-central-bakery. That name shows up in every event and makes it easy to find the right workflow.
2. Create the connection with the webhook already set. Point webhookUrl to the Webhook node of that client's n8n workflow.
3. Connect the number. If the client is next to you, QR code. If they're far away, a pairing code they type on their phone without scanning anything.
4. Test with a real message to the contact person's number and confirm the event reached the workflow.
5. Log it in your portfolio sheet: the identifier, the client plan and their technical contact.

Steps 2 and 3 fit in two calls:

# create the client connection, already pointing to the n8n workflow
curl -X POST https://api.d-api.cloud/api/v1/sessions \
  -H "Authorization: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "sessionId": "client-central-bakery",
    "type": "unofficial",
    "connectionMode": "pair",
    "pairPhone": "15551234567",
    "webhookUrl": "https://n8n.youragency.com/webhook/central-bakery"
  }'

# generate the code the client types on their phone
curl https://api.d-api.cloud/api/v1/sessions/client-central-bakery/pair-code \
  -H "Authorization: YOUR_API_KEY"

If you have many numbers per client, like a chain with several locations, the organization model is in multiple WhatsApp numbers.

n8n: what's native and what goes through a webhook

Most agencies build their workflows in n8n. D-API has a community node, n8n-nodes-d-api, that covers the actions: send text, media, lists, query data. It's an action node, not a trigger. For the workflow to react to incoming messages, use n8n's native Webhook node, with its URL set as the webhook of the client's connection.

In practice, that gives you a clean pattern: one inbound workflow per client, starting at the Webhook node, and D-API nodes to reply. The install walkthrough is on the n8n integration page. If your work is more about building automations than managing a portfolio, WhatsApp API for automation goes deeper on that side. And before designing inbound workflows, get to know the event format in WhatsApp webhooks.

Hands-off operations: know about a drop before the client does

What wears out an agency's relationship with a client the most is the client finding the problem first. D-API continuously self-heals connections, and most drops resolve without anyone stepping in. For those that don't, the connection.status event reports connected, disconnected or logged_out.

A simple monitoring workflow every agency should have:

• On disconnected, wait a few minutes and check the connection again. If it's still down, send an alert to the agency's internal group.
• On logged_out, the client unlinked the device or switched phones. Generate a new pairing code and send it to the contact person with a one-line instruction.
• Keep a drop history per client. It shows who needs guidance on how they use their number.

Passing on cost without a message spreadsheet

Per-message billing is bad for agencies: the cost changes every month, depends on campaigns the client decides alone and forces you to audit statements. On D-API billing is per connection, not per message. One client, one connection, one price you know on the day you send the proposal.

And the price per connection gets cheaper as your portfolio grows, so margin improves with every new client instead of shrinking. Check the tiers on pricing. If your model is selling WhatsApp as your own product, under your brand and your commercial relationship, that's reselling and a different conversation, described in WhatsApp API reseller.

To validate the onboarding flow with a pilot client, there's a 3-day free trial, no credit card. Agencies that also build custom software may want to read WhatsApp API for dev agencies.