Offline Queuing

When your WebSocket client is offline, Pipes.bot queues incoming messages and delivers them when you reconnect. No messages are lost during brief disconnections.

How queuing works

1. A WhatsApp message arrives while no matching connection is open
2. Pipes.bot stores the message in a Redis queue
3. When you open a user-scoped connection, all queued messages are delivered automatically
4. Messages are delivered oldest-first with a 750ms delay between each to avoid overwhelming your client

Queuing and connection scopes

Queuing behavior depends on which connections are active when a message arrives:

• At least one user-scoped connection open — message is delivered in real time, no queuing
• Only conversation-scoped connections open — message is delivered to matching connections; if no connection matches, the message is queued
• No connections open — message is queued

Queue drain only happens on user-scoped connections. Conversation-scoped connections do not trigger a drain to avoid partial queue complexity. If you rely on conversation-scoped connections exclusively, use the REST API or a separate user-scoped connection to handle queued messages.

Queue limits

Per-sender queues

Queues are scoped per sender. If 5 different people message you while offline, each sender gets an independent 100-message queue. This prevents a chatty sender from pushing out messages from others.

Overflow

When a sender's queue reaches 100 messages, the oldest message is dropped to make room for the new one. This ensures you always receive the most recent messages.

Drain behavior

When you open a user-scoped connection:

1. All queued messages across all senders are retrieved
2. Messages are sorted by timestamp (oldest first)
3. Each message is delivered with a 750ms pause between sends
4. The connection state is checked before each delivery — if you disconnect during drain, remaining messages stay queued
5. Queues are cleared atomically to prevent duplicate deliveries

Webhook fallback

If you're using webhook delivery and all retry attempts fail, the message is delivered via WebSocket as a fallback:

1. Webhook delivery attempted (up to 3 times with exponential backoff)
2. If all attempts fail, the payload is saved to the WebhookDelivery table
3. The message is delivered through the WebSocket connection (or queued if offline)

This ensures messages are never lost, regardless of your delivery method.

Offline notifications

When messages arrive while you're offline, Pipes.bot can send you an email notification so you know messages are waiting. Notifications are throttled to avoid flooding your inbox during high-traffic periods.