Why merchants ask for WhatsApp
Ask any small merchant where the "where's my order?" messages come from: the store's WhatsApp, answered by hand, one by one. They already talk to customers there all day. What they want from your platform is for the repetitive messages to go out on their own, from the same number, so they have time left to sell.
For whoever builds the platform, that becomes a product decision: WhatsApp as a native dashboard feature, sold as an add-on or bundled in a higher plan. Today many merchants patch it with a browser extension or a third-party app, and every side solution is order data leaving your ecosystem.
Shopify, WooCommerce or your own storefront
D-API doesn't ship a Shopify or WooCommerce app. It's the WhatsApp layer your product calls. If you build a Shopify app, a WooCommerce plugin or your own storefront platform, the pattern is the same: your backend receives the platform's order webhooks, decides which message to send and calls the API with the merchant's connection. The merchant sees WhatsApp as a feature of your product.
The four moments that drive the most results
Order confirmation
This is the message the customer expects. Order number, items, total and payment method. For bank transfers or pay-by-link orders, the confirmation includes a reminder that the order only ships after payment.
Tracking
Shipped, in transit, out for delivery, delivered. Ideally you send the tracking code once, with a link button to the tracking page, and only notify again on a meaningful change. The full flow is in order tracking on WhatsApp.
Abandoned cart
The customer entered their phone at checkout and didn't pay. A message one or two hours later, with a direct link to the cart, recovers part of those sales. This use case has its own page, with sequence and timing strategy: cart recovery on WhatsApp.
Catalog and new arrivals
A new collection, a sold-out product back in stock, a birthday coupon. An image with a caption covers most cases; for several products in one message there's the interactive carousel. Be more careful here: only for people who opted in, and at a low frequency.
Example: from order event to the customer's WhatsApp
Most platforms already emit internal events when an order status changes. The handler below listens to the shipping event and sends a message with a tracking button from the merchant's number:
import { DApi } from 'd-api-sdk'
const dapi = new DApi({ apiKey: process.env.DAPI_KEY! })
export async function onOrderShipped(order: Order) {
if (!order.customer.whatsappOptIn) return
await dapi.interactive.sendTemplate({
sessionId: `store-${order.storeId}`, // merchant connection
to: order.customer.phone, // e.g. 15551234567
title: `Order #${order.number} shipped`,
content: `Hi ${order.customer.firstName}! Your order left today via ${order.carrier}.`,
footer: order.storeName,
buttons: [{ type: 'url', title: 'Track delivery', url: order.trackingUrl }],
})
}The same design works for the other moments: one handler per event, the connection resolved from the store ID and the message built from the order data. Run it in a worker, outside the checkout request, so network latency never holds up the purchase.
Product checklist before rolling out to merchants
- WhatsApp opt-in at checkout, saved with the order, separate from email consent.
- Phone numbers normalized to international format without the plus sign, like 15551234567.
- Merchant-editable copy, with variables and a preview before saving.
- On/off per message type, so the merchant chooses what to send.
- Connection status visible in the dashboard, with a reconnect button when it drops.
- Customer replies routed to wherever the merchant handles support, not lost.
- A daily cap on promotional campaigns, protecting each store's number.
The last item matters more than it looks. A merchant who blasts a promotion to the whole base at once puts their own number at risk. Read how to avoid bans before releasing any campaign feature.
One connection per merchant, no domino effect
A platform with thousands of stores can't let an isolated problem become a platform-wide incident. On D-API each connection runs isolated, with its own credentials, webhook and IP, and self-heals when the drop doesn't depend on the merchant's phone. For your platform, each store is just a sessionId, and a single webhook URL receives events from all of them, identified by session.
The D-API WhatsApp API bills per connection, and the unit price goes down as the number of connected stores goes up (see pricing). The product design for software with WhatsApp built in is in WhatsApp API for SaaS. Talk to sales for a 14-day free trial, with guided implementation in a WhatsApp group.