SendBlue
SendBlue adds iMessage and FaceTime Audio to the agent workspace. Consent, quiet hours, and attempt caps apply to a blue bubble exactly as they do to a call, and every touch lands in the same ledger.
iMessage and FaceTime Audio, on the same queue.
iMessage under policy
Consent, quiet hours, and attempt caps are evaluated for iMessage as its own channel before every send.
FaceTime Audio click-to-call
Opens on the agent's device; DialSplice never carries the audio and records only the outcome.
Delivery and read outcomes
Delivered, read, and replied events come back; message bodies stay in SendBlue and your CRM.
Dispositions written back
Every conversation ends in a disposition on the work item and the CRM record.
Built during onboarding when the vendor exposes an API. We confirm feasibility in the demo before you commit.
Reads, writes, and never returns.
- Delivery, read, and reply events
- Inbound message metadata, not bodies
- Handle and number inventory
- Outbound iMessage under policy
- FaceTime Audio call intents
- Dispositions and outcomes
- Message bodies to the ledger
- Recordings
- Credentials to the browser
Credentials never reach the browser
Provider tokens live server-side; the agent's browser only ever sees a work item.
Scope on every request
Organization and location travel with each call to the connector; an unknown scope fails closed.
Idempotent, journaled, reconciled
Every effect is journaled once; an ambiguous outcome enters reconciliation instead of a retry.
What SendBlue is usually spliced with.
One connector per category. These are the systems we most often see beside SendBlue; any of them can be swapped for the one you run.
Other Messaging connectors.
SendBlue and DialSplice.
Who it is for, and what to ask before the demo.
Does DialSplice replace SendBlue?
No. SendBlue stays the messaging channel. DialSplice adds the queue, the contactability preflight, and the audit ledger on top, and hands work back to SendBlue where it belongs.
What does DialSplice store from SendBlue?
Work items, scope, timestamps, dispositions, event hashes, and operational telemetry. Identity is read from SendBlue under your scopes and is not copied into the ledger.
Is the SendBlue connector available today?
It is built on request during onboarding, when SendBlue exposes the API surface we need. We confirm feasibility in the demo before you commit, and quote it in writing.
Where do the SendBlue credentials live?
Server-side, always. The agent's browser only receives a work item; provider tokens never reach it, and every request carries organization and location scope.
See SendBlue spliced in.
Bring the rest of your stack; we will show you the workspace with every system named.