WhatsApp Business API

Overview

ERP-triggerable bulk messaging over the WhatsApp Business API. Campaigns, order and invoice notifications, appointment reminders — all from a single panel.

Sending messages

Per-session REST endpoints

• Separate send endpoints for text, images, video, audio, documents, stickers and locations.
• Media is supplied by URL or as base64; captions and file names can be added to images and documents.
• A message can get an emoji reaction, and a message you sent can be deleted.
• Message history is listable; statuses: pending, sent, delivered, read, failed.

Bulk sending

• One call starts a bulk send with a name, a recipient list and a shared text; each recipient can also carry its own text.
• You choose the pause between messages, in milliseconds.
• Each bulk job reports total, sent and failed counts and a status (queued, running, completed, cancelled, failed).
• A running bulk job can be cancelled.

Sessions and QR linking

Each WhatsApp account is a session. Sessions are created, started and stopped; the QR code is returned as an image.

• On your phone follow WhatsApp → Settings → Linked Devices → Link a Device and scan the QR code.
• Session states: initialising, QR ready, connecting, connected, disconnected, failed, stopped.
• The link is persistent; you only need to scan the QR again after a restart if the device was removed from the phone.
• A session's groups and contacts can be listed as well.

Incoming messages by webhook

• One or more webhooks are defined per session; you choose which events to receive, and the default is incoming messages.
• Events are delivered to your URL by HTTP POST; if you provide a secret the body is signed with HMAC-SHA256 and you can verify the signature from the header.
• Failed deliveries are repeated up to the retry count you set (3 by default).
• After saving a webhook, use the test endpoint to confirm your URL responds.

Authorisation and security

• Every request is authenticated with the X-API-Key header; keys are stored in the database only as a SHA-256 hash and only a short prefix is ever displayed.
• Three roles: Viewer (read), Operator (session, message and webhook actions), Admin (key management, session deletion, audit log).
• Optional per key IP allowlist (CIDR) and session scope: a restricted key reaches only the endpoints and lists of its own sessions.
• Only the health endpoints are open without authentication; the session-scope rule is locked in by tests.

Monitoring, statistics and auditing

• Live events: session and message events are followed per session over a real-time (SignalR) channel.
• Statistics: session, message and webhook totals with a per-session summary.
• Health: liveness and readiness endpoints without authentication; they never leak connection detail.
• Audit log: administrators can list the actions performed.
• Swagger: every endpoint is documented and can be tried interactively.

Installation and operation

• Data is kept in SQL Server; tables are created automatically on first start.
• Runs on your own server as a Windows service; a management panel (sessions, message tester, webhooks, API keys, logs) is provided separately.
• Endpoints are published behind HTTPS and can be monitored through the health endpoint.
• Usage examples for C#, VB.NET, Java and curl are on the product's landing page.