Skip to main content

No backend queue

BlueSender does not queue outbound messages. When the Mac client bound to a locationId is offline, POST /crm/webhook (and its aliases /crm/webhook/imessage, /crm/webhook/sms) fails immediately with HTTP 404 in the common case. The request is not buffered, replayed, or retried by the backend.

There is one edge case where the response can briefly be a misleading 200 OK: if the Mac disconnected within the last ~60 seconds, its Redis routing lease (location:<locationId>) may still be live for a few more seconds. During that window BlueSender publishes the webhook onto the owning instance's pub/sub channel and returns success — but no Mac is there to receive it, so the message is dropped on the backend side without a 404 or a failed callback. The lease expires within ~60 s and subsequent webhooks return 404 normally. CRMs that care about this edge case should rely on the delivered / failed status callback (when messageId is sent) as the source of truth, not on the synchronous HTTP status alone.

The 404 response​

{
  "error": "Location not connected",
  "locationId": "<your-location-id>",
  "message": "No Mac client connected for locationId: <your-location-id>"
}

There is no code field on this HTTP response — error is the short label "Location not connected".

Status-update callback​

If BlueSender can resolve a message ID from your POST /crm/webhook request (see the resolution order), it also delivers a structured failure to your CRM through the status-update channel (PUT /conversations/messages/{messageId}/status):

{
  "status": "failed",
  "error": {
    "code": "CLIENT_NOT_CONNECTED",
    "type": "error",
    "message": "No Mac client connected for locationId: <your-location-id>"
  }
}

This is the only place CLIENT_NOT_CONNECTED appears as a structured error code; the synchronous HTTP 404 body does not include it. When no resolvable ID is present, the synchronous 404 is the sole indicator.

Why no queue​

The backend treats outbound delivery as best-effort against a currently-online Mac. There is no per-locationId buffer, no arrival-order replay, and no overflow handling — those mechanisms simply do not exist in the implementation today.

What this means for CRMs​

The CRM is the durable system; BlueSender is a real-time bridge. Concretely:

  • Track delivery state in the CRM, not in BlueSender. Treat the HTTP 404 from POST /crm/webhook (and the matching CLIENT_NOT_CONNECTED status callback when messageId is sent) as the source of truth that the message did not reach the Mac.
  • Retry from the CRM side if the message still needs to be delivered. A common pattern is: on 404, mark the CRM message as pending-redelivery and retry on a back-off schedule.
  • Don't assume messages sent during a Mac outage will eventually arrive on their own. They will not. If your CRM has been generating outbound while the Mac was offline, plan a reconciliation pass once the Mac is back online — the CRM is the only system that knows what was emitted.

Brief disconnects​

A brief Mac reconnect (network blip, app restart) typically takes a few seconds. During that window every POST /crm/webhook for that locationId will return HTTP 404 until the Mac comes back online. Your CRM should treat this as the normal failure path, not as a bug.