WhatsApp API for ERP: documents and updates that send themselves

The manual work your ERP still leaves to the user

The ERP issues the invoice, generates the bill and closes the order. After that, someone in finance opens the PDF, saves it to the desktop, opens WhatsApp Web and sends file after file. At a small company, that routine eats a whole morning at month-end. At a mid-size company, it becomes someone's job.

Email only solves it on paper: the bill lands in spam, the customer says they never got it and collection is late. When the ERP itself sends the document from the company's WhatsApp, that step disappears and your users notice the difference in the first week.

Event map: what the ERP already knows becomes a message

The ERP is the system with the most ready-made triggers. Almost every status change already exists in your database; it just needs to be wired to the WhatsApp API.

None of these sends depends on someone remembering. The rule lives in the ERP, versioned with the rest of the product, and each client company turns on or off whatever it wants in the settings.

Example: invoice issued, PDF on WhatsApp

In the handler that runs when the invoice is issued, one call is enough. The PDF needs to be at a URL the API can reach (a short-lived signed link from your storage works) or go in base64:

curl -X POST https://api.d-api.cloud/api/v1/messages/send/document \
  -H "Authorization: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "sessionId": "erp-company-4821",
    "to": "14155550123",
    "document": "https://storage.yourerp.com/invoices/inv-2026-012345.pdf",
    "fileName": "Invoice-12345.pdf",
    "mimetype": "application/pdf",
    "async": true
  }'

The fileName is what the end customer sees on the attachment, so use something readable like "Invoice-12345.pdf" instead of an internal id. async returns a commandId right away and frees up the billing process; the result of each send is available to query or arrives via webhook. Other file formats are covered in send images, audio and files.

One connection per client company, not one for the whole ERP

The most expensive mistake in this kind of integration is sending everything from one central number owned by the ERP. The end customer gets an invoice from a sender they don't know, replies asking about the order and nobody at the company sees it. On top of that, a problem with that number stops billing for every company in your base at the same time.

The right design is for each company registered in the ERP to connect its own number. On D-API that means creating one connection per company (or per branch) via API, with the internal company id in the sessionId and in metadata. Each connection runs isolated with its own IP, so a distributor's number that ran into trouble doesn't affect the bakery on the same ERP. That is the model described in WhatsApp API for SaaS, billed per connection and not per message, which fits the uneven volume of month-end closing.

Implementation roadmap in the ERP

1. Setup: on the company settings screen, add "Connect WhatsApp". The ERP creates the connection via API and shows the QR code for the person in charge to scan.
2. Reliable phone numbers: store customer mobile numbers in international format, such as 14155550123 or 447700900123. This is where most sends fail.
3. First trigger: start with a single document, usually the bill, with an option to turn it off per company.
4. Log per document: store the commandId with the invoice or bill, so support can answer "it was sent at 2:02 PM" without opening a ticket.
5. Connection status: listen to connection.status and show an alert in the dashboard when a company's number disconnects, before the company finds out from a customer.
6. End customer replies: forward messages.received to the responsible user in the ERP, or to a support team if the company has one.

Watch out for volume and for billing documents

• Spread out month-end: hundreds of bills in the same minute from a newly connected number is a pattern that tends to lead to restrictions. Use a queue with a per-connection pace and check the connection's /api/v1/limits route to see its message quotas.
• Expiring links: invoice PDFs contain buyer data. Generate the signed URL at send time and let it expire shortly after.
• Per-contact opt-out: a customer who asked to get documents by email only needs a flag on their record that the ERP respects.

Recurring billing has its own nuances, covered in payment reminders, and order status updates in transactional notifications. To roll this out across your base, the 14-day free trial available through sales includes implementation support.