Knogin
[Developers]

Multi-Provider Omnichannel Messaging

During an active emergency, dispatchers route calls and messages through Twilio, then a department switches carriers to VoIP.ms for cost reasons, and suddenly every integration breaks. The Multi-Provider Omnichannel Mess

Back to All Modules
Category: Data IntegrationLast Updated: Jun 4, 2026
data-integrationreal-time

Overview#

During an active emergency, dispatchers route calls and messages through Twilio, then a department switches carriers to VoIP.ms for cost reasons, and suddenly every integration breaks. The Multi-Provider Omnichannel Messaging module unifies SMS, MMS, WhatsApp, RCS, and Signal messaging behind a single, portable provider adapter. Organisations swap carriers without rewriting dispatch logic; inbound callbacks route automatically to the right tenant; tenant credentials move with the organisation, not baked into platform settings.

The module provides a vendor-agnostic messaging dispatch layer that normalises all carriers onto one interface. Every provider (Twilio, VoIP.ms, Signal) implements the same MessagingProviderAdapter contract: send an outbound message, verify inbound webhook signatures, normalise inbound payloads. Conversations and message history layer on top, tracking unread counts, starred messages, and last message content.

Key Features#

  • Provider Abstraction: Single MessagingProviderAdapter interface hides vendor specifics (Twilio HMAC-SHA1 signatures, VoIP.ms api_key shared secrets, Signal JSON-RPC), so dispatchers never branch on the provider.
  • Multi-Channel Support: Carries SMS, MMS, WhatsApp, RCS (Twilio), SMS/MMS (VoIP.ms), and Signal on one normalised transport; channel is selected per message, not per tenant.
  • Portable Per-Tenant Credentials: Credentials stored in the tenant's own provider configuration, not in platform environment variables, so credentials and configuration move with the tenant to any deployment.
  • Automatic Inbound Routing: Tenant is resolved from inbound DID or phone number; webhooks from any provider route to the correct organisation without manual lookup tables.
  • Vendor-Neutral Message Model: OutboundMessage and InboundMessage types abstract away prefixes (whatsapp:, rcs:), webhook payload shapes, and vendor-specific metadata; all that variation stays inside the adapter.
  • Conversation State Tracking: Unread message counts, last message content, and starred message flags are persisted per conversation, enabling UI to show engagement state and quick reference without re-fetching history.
  • Webhook Signature Verification: Each adapter implements constant-time signature verification (HMAC-SHA1 for Twilio, HMAC for VoIP.ms, signal-cli poll-based) to prevent spoofing.
  • Provider Resolution Priority: Tenant-configured provider (from database) is tried first; platform/environment fallback only applies when the tenant has no own configuration, ensuring a tenant's carrier choice is never masked by platform settings.

Use Cases#

Multi-Carrier Deployment#

Organisations operating across multiple regions or cost-optimising their carrier mix provision different providers per tenant without touching code. A regional centre uses Twilio for reliability; a satellite office uses VoIP.ms for cost. Both dispatch through the same omnichannel service.

Carrier Migration#

When switching from Twilio to VoIP.ms (or vice versa), update the tenant's credentials in the database, and inbound/outbound immediately routes to the new carrier. No re-deployment, no code changes, no downtime for message dispatch.

Encrypted Messaging with Scale#

Support WhatsApp and Signal alongside SMS/MMS, each with its own vendor (Twilio for business messaging, signal-cli for encrypted peer-to-peer). Dispatchers type a message once; the platform picks the right channel per contact.

Portable Emergency Communications#

When an agency deploys to a satellite or remote office with limited connectivity, carry omnichannel credentials in the tenant configuration. Messaging works immediately because there are no hard-coded secrets or environment assumptions.

Integration#

Organisations integrate by provisioning telephony provider credentials (per vendor's documentation) in the tenant's own provider configuration. The registry resolves the right adapter for a (channel, tenant) pair at request time, fetching credentials from the database first, then falling back to platform settings for back-compatibility.

Outbound flow: create an OutboundMessage with the recipient, content, and channel; call the resolved adapter's send method; receive a normalised SendResult indicating success, provider, message ID, and any vendor-specific status. Inbound flow: receive a webhook from the carrier; the adapter's verify_inbound method validates the signature (or shared secret) using constant-time comparison; call normalize_inbound to convert the vendor payload to an InboundMessage; route to conversations and persist.

Per-tenant credentials are resolved from the organisation's own database rows (portable) before platform environment variables (legacy fallback), ensuring that multi-tenant deployments do not share or leak credentials across organisations. Inbound callbacks authenticate via the signature or secret tied to the tenant, routing automatically without manual DID lookup tables.

Open Standards#

  • ITU-T E.164: All phone numbers across every provider (Twilio, VoIP.ms, Signal) are normalised to E.164 format (leading +, digits only) before routing, conversation matching, and persistence, preventing injection and number-mismatch errors.
  • HMAC-SHA1 (RFC 2104): Twilio inbound webhook signatures (X-Twilio-Signature) are validated using HMAC-SHA1 with constant-time comparison, exactly per Twilio's published signing scheme.
  • JSON-RPC 2.0: The Signal adapter communicates with the signal-cli daemon via JSON-RPC, sending and receiving message envelopes in the signal-cli JSON-RPC protocol shape.
  • ISO 8601: Inbound message timestamps (received_at) and all real-time WebSocket broadcast timestamps are expressed in ISO 8601 format, ensuring interoperability across time zones.
  • RFC 4122 UUID: Conversations, messages, channels, and verification records are all keyed by RFC 4122 UUIDs, giving stable, globally unique identifiers across multi-tenant deployments.
  • WebSocket (RFC 6455): Real-time dispatcher updates (new messages, conversation state changes) are pushed to PSAP dashboards over WebSocket connections, scoped per tenant.
  • HTTPS / TLS (RFC 2818): All outbound carrier API calls (Twilio Programmable Messaging REST endpoint, VoIP.ms REST API) are made exclusively over HTTPS, and inbound webhooks are expected on HTTPS endpoints.

Security & Compliance#

  • Constant-Time Signature Verification: All webhook signatures are compared in constant time to prevent timing-based attacks that could distinguish valid from invalid signatures.
  • Portable Credentials: Provider secrets are stored per-tenant in the database, not in platform environment variables, reducing the surface for cross-tenant credential leaks and enabling secure multi-tenant isolation.
  • Webhook Authentication: Every inbound webhook is authenticated against the provider's shared secret or HMAC signature before the payload is normalised or persisted, preventing spoofed messages.
  • E.164 Normalisation: Phone numbers are normalised to E.164 format (leading +, no spaces) across all channels, preventing injection attacks and number mismatch issues.
  • Secrets Logging Safety: Credential resolution failures are logged without exposing key values; only the tenant ID and resolution status are recorded.

Availability#

  • Enterprise Plan: Included
  • Professional Plan: Available as add-on

Last Reviewed: 2026-06-04 Last Updated: 2026-06-05

Ready to Build?

Get started with our APIs or contact our integration team for support.