Messages, media, contacts, locations, reactions, interactive replies, and delivery status.
Unified inbox
Five customer channels. One place to work.
SignalBX brings verified inbound WhatsApp, Email, SMS, Viber, and RCS messages into one normalized conversation view while preserving the channel details behind each event.
Sender, recipient, subject, plain or HTML-derived text, reply references, and delivery events.
SMS
Text messages from JSON or form webhooks with provider IDs and mapped delivery status.
Viber
Text, pictures, video, files, stickers, locations, contacts, and seen status.
RCS
Text, media, rich-card content, agent context, and delivery receipts.
One operating view
Change channels without changing how the team works.
Every configured adapter produces the same SignalBX-owned message shape, so channel, sender, conversation, content, timestamps, and status can appear together without flattening away useful provider detail.
Aarav MehtaCan I change my delivery address?WhatsApp · now
NewSarah KimReturn request · Order #10428Email · 2 minutes
Nina RaoWhere is my delivery?SMS · 4 minutes
Leo MartinPhoto · item arrived damagedViber · 7 minutes
Maya ShahRich card · size availabilityRCS · 9 minutes
Aarav MehtaWhatsApp · inbound conversation
Received- Channel
- Content type
- Text
- Sender
- Customer identity preserved
- Status
- Received
Channel-native input
Normalize the work, not the useful details.
Each adapter understands its provider’s webhook shape and carries channel-specific fields into canonical content, threading, status, raw payload, and metadata.
- Keep provider message IDs for stable duplicate protection
- Map delivery events into shared received, sent, delivered, read, or failed states
- Represent unsupported payload types explicitly instead of silently dropping them
Text, image, video, audio, documents, stickers, locations, contacts, reactions, templates, and interactive replies.
From, to, subject, message ID, reply reference, plain text, and readable text derived from HTML.
SMS
JSON or form payloads with sender, recipient, message body, provider ID, and delivery event mapping.
Viber
Text, pictures, video, files, stickers, locations, contacts, conversation starts, and seen events.
RCS
Text, media, rich cards, sender phone, agent ID, timestamps, and provider delivery receipts.
One ingestion contract
Provider webhook in. Canonical message out.
The adapter boundary keeps provider parsing separate from the inbox. Every accepted event passes through authentication, idempotency, normalization, and tenant-scoped storage before it becomes shared conversation state.
Webhook boundaryVerify the configured channel secret
AuthenticatedDuplicate protectionDerive a stable provider event key
IdentifiedAdapter contractNormalize content, thread, and status
CanonicalInbox statePersist the tenant-scoped conversation event
AvailableShared message model
One shape behind every channel row.
The inbox can reason about the same core fields across all five channels while provider-specific details remain available in channel metadata and content extras.
channel
conversationId
content
thread
status
CanonicalMessage · selected fields{
"channel": "email",
"direction": "INBOUND",
"channelMessageId": "message-10428",
"conversationId": "email:[email protected]",
"senderId": "[email protected]",
"recipientId": "[email protected]",
"content": {
"type": "TEXT",
"text": "Can I return order #10428?",
"channelExtras": {
"email_subject": "Return request"
}
},
"thread": {
"channelReplyToId": "message-10412"
},
"status": "RECEIVED"
}Shared delivery language
Status events belong beside the conversation.
Channel-specific receipts are mapped into a compact status history so the inbox can show message progress consistently across provider vocabularies.
Received
An authenticated inbound message has entered the tenant’s canonical conversation stream.
Inbound messageSent
A provider reports sent, accepted, queued, or deferred delivery state.
Provider eventDelivered
The channel reports that the message reached the recipient endpoint.
Delivery receiptRead
The provider reports read, seen, or open where that channel exposes it.
Read receiptFailed
Failed, undelivered, bounced, or dropped events remain visible for follow-up.
Failure stateChannel events, handled
The details that keep an inbox trustworthy.
A customer sends a document.
The canonical content retains its document type, media reference, MIME type, caption, and filename.
Typed contentA customer replies by email.
The normalized thread carries the provider’s In-Reply-To reference while retaining subject and addresses.
Reply relationshipA provider posts form data.
The adapter accepts JSON or form-encoded input and maps common sender, recipient, body, and ID fields.
Provider normalizationA customer sends a location.
The location becomes typed canonical content with latitude and longitude instead of opaque text.
Structured locationA customer responds to a rich card.
Rich-card title or description is retained with the original card in channel extras.
Interactive contextA provider retries a webhook.
Stable provider IDs are preferred for idempotency, with deterministic fallbacks when no ID exists.
Duplicate protectionA dependable channel boundary
Verified, deduplicated, and accountable.
A unified inbox is only useful when provider events enter through explicit contracts and remain traceable after normalization.
- Verified webhooks
- WhatsApp, Viber, and RCS use HMAC-based verification; Email and SMS use configured shared-secret headers.
- Stable idempotency
- Provider message and event IDs are preferred, with hashed payload fallbacks when a stable ID is unavailable.
- Raw event retention
- The canonical record keeps the raw provider payload for traceability alongside normalized fields.
- Explicit content types
- Text, media, document, location, contact, reaction, template, interactive, and unsupported content stay distinguishable.
- Status history
- Delivery events append shared status updates and retain their channel event IDs where the provider supplies them.
- Tenant boundaries
- Channel configuration, authentication, canonical messages, conversations, and inbox queries remain tenant scoped.
Unified inbox questions
What teams need to know before connecting channels.
Which channels does this inbox page cover?
This page focuses on the first-party inbound adapters for WhatsApp, Email, SMS, Viber, and RCS. SignalBX also has adapters for other channels, but they are intentionally outside this page’s scope.
Does SignalBX store every channel in the same format?
Yes. Accepted events become SignalBX-owned canonical messages with shared sender, recipient, channel, conversation, content, thread, timestamp, status, and metadata fields.
Are provider-specific details lost during normalization?
No. Shared fields drive the inbox, while provider-specific details remain in channel metadata, content extras, and the retained raw payload.
Can every channel send outbound messages natively?
No. The five channels on this page have inbound adapters, but native outbound registration is not identical across them. WhatsApp has a first-party sender; Email, SMS, Viber, and RCS are presented here as inbound inbox sources.
How are duplicate provider webhooks handled?
Adapters derive idempotency keys from stable provider IDs whenever possible. When a provider event has no usable ID, SignalBX uses a deterministic hashed fallback before storage.
What happens when a channel sends an unknown content type?
The adapter can represent it as unsupported canonical content with channel-specific details, making the limitation visible instead of silently treating it as ordinary text.
Five channels, one queue
Bring every inbound conversation into view.
Connect WhatsApp, Email, SMS, Viber, and RCS through explicit adapter contracts—and give the team one normalized place to see the customer message and its channel state.