WhatsApp API with multiple numbers running in parallel

When one number is no longer enough

One number works well for a small business. The problem shows up when the operation splits, and each part needs its own WhatsApp:

• Different teams. Sales, support and billing on separate numbers, so the customer knows who they are talking to and each team has its own queue.
• Branches and locations. Each store, clinic or franchise keeps the number local customers already know, with the data centralized in the same system.
• Customers of a software product. The most demanding case: a CRM, helpdesk or ERP where each customer connects their own number. Here you have dozens or thousands of numbers, owned by different people.
• Spreading volume. High-volume operations split the load across numbers to respect the pace of each one.

In all of these cases, the WhatsApp API design is the same: one session per number, and your system as the layer that decides who speaks through which number.

One session per number

On D-API, adding a number means creating another session. You choose the sessionId, so it pays to use an identifier that already exists in your database, like the branch or customer ID. Each session can have its own webhook URL from the moment it is created:

for branch in downtown north south; do
  curl -X POST https://api.d-api.cloud/api/v1/sessions \
    -H "Authorization: YOUR_API_KEY" \
    -H "Content-Type: application/json" \
    -d "{ \"sessionId\": \"branch-$branch\", \"type\": \"unofficial\",
          \"webhookUrl\": \"https://your-app.com/wa/branch-$branch\" }"
done

Then each location scans its own QR code. To list what exists on the account, use GET /api/v1/sessions; to check the state of a specific session, GET /api/v1/sessions/{sessionId}. For software vendors, this loop usually becomes part of onboarding: the customer signs up for your product, your backend creates the session through the API and shows the QR code on screen, with nobody from your team in the middle.

Isolation: why one number must not take down the others

Running many numbers together creates a risk that does not exist with just one: the domino effect. If they all share the same process, a stuck session eats resources from the others. If they all go out through the same IP, one badly behaved number hurts the reputation of its neighbors.

On D-API, each connection runs isolated, with its own credentials and webhook, and gets a dedicated proxy with a unique IP, managed by the platform. When a session drops, auto-reconnect happens for that session only. For a SaaS, this means one customer's problem stays one customer's problem, instead of turning into a platform-wide incident with dozens of tickets opened at once. Keep in mind that isolation limits the damage, but it does not replace good sending practices; the recommendations are in how to avoid bans.

Per-session webhooks and routing

There are two ways to receive events from many numbers, and both work:

Within each session, you can go further and send each event type to a different URL with per-event configuration. A common example is splitting incoming messages, which go to support, from status changes, which go to monitoring:

curl -X POST https://api.d-api.cloud/api/v1/sessions/branch-downtown/webhook-config \
  -H "Authorization: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "enabled": true,
    "type": "per_event",
    "events": {
      "messages.received": { "enabled": true, "webhookUrl": "https://your-app.com/support" },
      "connection.status": { "enabled": true, "webhookUrl": "https://your-app.com/monitoring" }
    }
  }'

On your side, routing is a simple lookup: given the sessionId, which customer, which queue and which agent. Keep that mapping in a table and answer the webhook fast; heavy processing belongs in a queue of your own.

What to monitor when you have many numbers

• Status per session. A dashboard showing how many sessions are connected, how many disconnected and how many logged_out, fed by the status event.
• Notify the number's owner. When a session goes logged_out, the person who needs to scan the QR code again is the customer or the branch. Notify them directly, in your UI or by email.
• Sending per session. Pause automated sends for a session that is not connected, instead of piling up errors.

If your case is software with one number per customer, the WhatsApp API for SaaS page shows the full model. To connect each number, see connecting with a QR code, and to estimate the cost with many connections, check the pricing page.