Z-API alternative: the same WhatsApp API, built for many connections

Why companies look for a Z-API alternative

Switching providers takes work, so nobody does it on a whim. Among the teams that come to D-API, the reasons repeat and rarely have to do with a one-off failure:

• The product now has one number per customer. One connection became fifty. The question changes from "can I send?" to "what happens to the other forty-nine when one number has a problem?".
• A large customer asked for the official API. Without losing the customers who connect by QR code, the team wants to serve both profiles without maintaining two different integrations.
• Cost has to track margin. Anyone reselling WhatsApp inside a SaaS product wants the cost per connection to drop as the customer base grows.
• Less time firefighting. The product team wants connections to recover on their own and alerts to arrive before the customer complains.

Z-API and D-API side by side

The table below only uses what Z-API publishes on its own website and docs. Where we found no official information, it says to check with the vendor, because terms change and the right source is whoever sells it.

Both charge per connection, not per message. The difference is the price of each connection and how the infrastructure behaves as the number of connections grows.

Pricing: Z-API vs D-API

The comparison uses the Z-API Partner program price table, the terms they offer to accounts with 10 or more instances, checked on September 25, 2026. Z-API publishes prices in Brazilian reais (BRL), so we show them as published, without converting currencies. D-API prices are from the Scale plan, billed in US dollars, where the tier price applies to every connection on the account.

Z-API's lowest Partner price is R$54.99 (BRL) per instance, for accounts above 2,000 instances. On D-API, teams below 10 connections also get a price: from 1 to 9, $15.00 per connection, with no minimum. Above 50 connections, talk to sales: the price keeps dropping. Details are on the pricing page.

What changes in practice with D-API

Every number runs in isolation

On D-API, each instance runs in its own environment, with its own credentials and webhook, and an IP that isn't shared with other numbers. For a SaaS product, that means a customer who sends outside best practices doesn't drag the others down with them. To understand what drives bans, see how to avoid a WhatsApp ban.

Official and unofficial through the same API

D-API is a WhatsApp API where the official and unofficial connections use the same send routes. The type is set when you create the session (unofficial or cloud_api). When that large customer asks for the official API, you create their connection with the other type and the rest of your code stays the same. More on the official WhatsApp API.

Webhooks that retry

If your server goes down, D-API makes up to 7 delivery attempts for each event, with exponential backoff between them. That's what keeps you from losing incoming messages during a deploy.

Migration guide from Z-API to D-API

The first step is translating concepts. Most of them map directly:

With the mapping in hand, the migration takes four steps:

1. Isolate the provider in your code. Create an internal interface with the operations you use (create connection, generate QR code, send text, send media) and route the current implementation through it.
2. Implement the D-API adapter. In Node.js, the SDK covers most of it:

import { DApi } from 'd-api-sdk'

const dapi = new DApi({ apiKey: process.env.DAPI_API_KEY })

// one session per customer of your product
await dapi.sessions.create({
  sessionId: 'customer-4821',
  connectionMode: 'qr',
  webhookUrl: 'https://your-app.com/webhooks/whatsapp',
})

const { qrCodeImage } = await dapi.sessions.getQRCode('customer-4821')

await dapi.messages.sendText({
  sessionId: 'customer-4821',
  to: '14155550123',
  text: 'Your WhatsApp is now connected to the new system.',
})

3. Adapt your webhook receiver. D-API events arrive in an envelope with event, sessionId and data. An incoming message is messages.received, a connection change is connection.status. Translate them into the format your system already uses and the rest of your code won't notice the switch. Each event is detailed in WhatsApp webhooks.
4. Move numbers in batches. For each customer, create the session, show the QR code in your UI and, after confirming connected, shut down the old instance. Start with internal or test customers.

Checklist before turning off Z-API

• Every send your product makes (text, media, lists, groups) goes through the new adapter.
• Incoming message, read and connection status events are reaching your endpoint.
• Your system reacts to the disconnected status and notifies the right customer.
• Each migrated customer has its own session, with the sessionId stored in your database.
• Your support team knows how to generate a new QR code if a customer changes phones.

If your use case is WhatsApp inside a product with many customers, the WhatsApp API for SaaS page goes deeper into that scenario. To compare with other options, see the Evolution API alternative and the guide to multiple WhatsApp numbers. Volume plans are on the pricing page, and the 3-day free trial, no credit card, lets you test before moving any customer.