A WhatsApp delivery service that survives disconnection
An Express service wrapping whatsapp-web.js with a persistent on-disk queue, so messages sent while WhatsApp is disconnected are delivered on reconnect.
- Client
- Internal platform service
- Sector
- Messaging infrastructure
- Shipped
- 2025
- Practice
- Business process automation
A small HTTP service that other applications call to send WhatsApp text and media messages to individuals and groups. Its reason for existing is the queue: requests accepted while the underlying WhatsApp client is disconnected are written to disk and delivered once the session comes back, so a caller never has to care whether the session was alive at that moment.
The problem
A WhatsApp session that depends on a linked device will drop. When it does, naive integrations either throw an error back at the caller or silently lose the message. Neither is acceptable when the message is a lab report or an order confirmation.
What we built
- 01
A single HTTP surface for sending text and media to individuals and groups, so callers do not embed WhatsApp specifics.
- 02
A persistent on-disk queue: accept the request, acknowledge it, deliver it when the client is connected.
- 03
QR-code pairing in the terminal for session setup, with the session persisted so a restart does not mean re-pairing.
- 04
Patched upstream dependencies where behaviour needed to change, kept reproducible through patch-package.
What it does now
- Callers get an acknowledgement rather than an error during a disconnection.
- Nothing queued is lost across a restart of the service.
- One integration point for every internal application that needs to send on WhatsApp.
What people ask about this work.
What happens to a WhatsApp message if the session is disconnected?
In this service the request is accepted, acknowledged and written to a persistent on-disk queue, then delivered once the client reconnects. The calling application does not need to know whether the session was alive when it made the request.
Is whatsapp-web.js suitable for production?
It works, with caveats. It depends on a linked device and an unofficial interface, so sessions drop and behaviour can change without notice. We use it where a durable queue absorbs the instability, and we recommend the official Cloud API where templates, scale and formal support matter.
Related projects.
- Analyser integration
Middleware that reads a haematology analyser
Middleware for a Mindray BC-series haematology analyser, turning a printed slip and twenty retyped numbers into a result that arrives by itself.
Read it - HL7 integration
An HL7 bridge and report builder for a diagnostics chain
A bridge carrying HL7 messages from laboratory instruments into a cloud platform, with a drag-and-drop report builder and generative AI assistance.
Read it