Unified Messaging Intelligence

Most messaging platforms expose separate APIs for SMS, WhatsApp, RCS, and other channels. That means developers end up writing routing code, handling edge cases, and debugging delivery problems across multiple providers. Sent takes a different approach: instead of giving you channel-specific APIs, Sent gives you a single interface that understands your intent (what you want to send, to whom, and why) and figures out the best way to deliver it.

The Intelligent Architecture

When you integrate directly with channel APIs, you run into the same problems every time:

• Integration Sprawl: Each channel has different auth, payload formats, error codes, and quirks.
• Business Logic Scattered Everywhere: Your app logic gets littered with “if WhatsApp, do this; if SMS, do that; if RCS, do something else,” making the code harder to maintain.
• You Own the Routing Logic: You’re responsible for retries, fallbacks, and figuring out what channels are available for a given phone number as well as which channel is fastest, cheapest, and most reliable.

Sent flips that around: you implement messaging into your app once, and the platform handles channel selection, routing, retries, and compliance.

Imperative vs. Declarative Messaging

The two integration styles differ in where the routing knowledge lives. Imperative code encodes channel decisions in your app; declarative code states the intent and leaves the decision to the platform:

Imperative messaging:

if (user.hasWhatsApp && templateApproved) {
  await whatsappAPI.send(whatsappTemplate, user.whatsappId);
} else if (user.hasSMS) {
  await smsAPI.send(smsMessage, user.phoneNumber);
}

Declarative messaging with Sent:

await sent.sendMessage({
  phoneNumber: "+1234567890",
  templateId: "order_confirmation",
  templateVariables: {
    orderId: "12345",
    total: "$99.99"
  }
});

The imperative version already contains two channel checks and no fallback handling; every new channel, region, or compliance rule adds another branch. The declarative version stays the same size as those concerns grow, because they are absorbed by the platform. The Sending Messages guide shows the declarative call in full, including how to pin a channel explicitly when you need to.

Messaging complexity shouldn’t live in your codebase. Sent centralizes it as infrastructure:

• Absorbed Complexity: Multi-channel routing, compliance, and optimization handled once, not by every app.
• Centralized Expertise: Sent maintains the industry rules, carrier quirks, and provider integrations.
• Faster Innovation: New features and integrations roll out at the platform level.

The Decision Engine

Real-Time Routing

Every message you send through Sent is resolved by a routing engine at send time, after the API has accepted the request. For each recipient, the engine weighs:

• The requested channel: a pinned channel (sms, whatsapp, rcs) restricts routing to that channel; the default auto-detect channel lets the engine choose.
• Routing rules: rules matched on the recipient (country, number prefix, carrier, number type), the sender, the template, and the channel. Account-scoped rules take precedence over global ones, and more specific matches over less specific ones.
• Channel capability: whether the recipient is registered on WhatsApp, whether the device supports RCS, and whether the template is approved on each candidate channel.
• Compliance gates: recipient consent and account preconditions are checked before any route is attempted.

The matching rules form an ordered candidate list: the first candidate wins and the message dispatches on it, while the remaining candidates are held as fallback routes. There is no fixed channel preference order: the winner depends on which routes exist for your account and the recipient. The factors that decide among viable channels are summarized in Routing Factors, and the exact matching and ordering rules are specified in the channel routing reference.

Fallback

When a route fails, Sent walks the fallback candidates that routing already resolved instead of giving up on the message:

How the fallback path behaves:

• Failed submission to a provider → the next candidate route is attempted, when the matched rule allows fallback. That next route may be the same channel through a different provider, or a different channel on auto-detect sends.
• Accepted, then reported as failed → the message re-enters routing only when the failure is one a different route might overcome, such as a provider outage, timeout, or a WhatsApp recipient-side failure (the path behind WhatsApp-to-SMS fallback). Routes already attempted are excluded, and a message attempts at most 3 distinct routes.
• Permanent failures (invalid number, opted-out recipient) → the send stops and the terminal status is reported.

Consent is re-checked on every reroute, so an opted-out recipient never receives a fallback attempt. Each attempt and the terminal outcome surface as status webhooks. See Message Status Tracking for observing this lifecycle from your app.

Multi-Provider Orchestration

Sent plugs into multiple carriers and APIs, normalizing the differences:

• Provider Abstraction: One interface to SMS providers, WhatsApp Business API, RCS providers, and others.
• Health Monitoring: Real-time checks on provider reliability and limits.
• Load Balancing: Spreads traffic across providers for cost, capacity, and performance.

Regulatory Compliance

Built-In Regulatory Compliance Logic:

• Global Rules: Sent tracks country-specific restrictions and applies them at send time.
• Consent Enforcement: Opt-ins/outs applied consistently across all channels.
• Content Validation: Automatic checks against carrier and platform rules.

Template Approvals (WhatsApp):

• Submission Automation: Templates formatted and submitted through each channel's approval flow automatically: Meta for WhatsApp, carrier verification for RCS.
• Status Tracking: Approval state synced back into your system.
• Retry Logic: Failed approvals reworked and resubmitted.

Always Learning

The routing engine learns from real delivery data:

• Pattern recognition → what works best by region, channel, time
• Anomaly detection → auto-adapts to outages and disruptions
• Route tuning → balances cost, reliability, and engagement

Network Effects

Because all apps share the same intelligence layer, everyone benefits:

• Shared learnings → improve delivery everywhere
• Regional insights → drive smarter defaults
• Carrier relationships → are used at platform scale

Template-Driven Intelligence

Templates as Config, Not Hardcoded Messages

Templates let you describe intent (“confirm order,” “welcome user”) without worrying about formatting differences between SMS, WhatsApp, and RCS. Sent adapts them automatically. For RCS, templates can include an rcs channel override that defines rich card layouts, suggestion chips, and carousel cards, while the same template ID delivers plain text on SMS:

• Built-in compliance (WhatsApp approval, SMS opt-in, regional rules)
• Rich formats where the channel supports them (plain text everywhere else)

How this adaptation works is the subject of the Templates concept page; Working with Templates shows how to build and publish one.

Variables for Dynamic Content

• Type-safe: Variables know their types and adapt across channels
• Context-preserving: Business meaning stays intact while formatting adjusts
• Fallback values: Missing/invalid variables degrade gracefully

Built for Change

Messaging isn’t static. New channels, new compliance rules, new algorithms. Sent’s architecture is designed to absorb this without you rewriting your code:

• Plug-in new channels without changing your app
• Routing algorithms auto-upgrade as Sent improves them
• Compliance handled at the platform level, so you stay safe without extra work

Sent’s unified messaging intelligence removes multi-channel complexity from your codebase by abstracting away provider APIs and routing logic. You express intent, Sent handles delivery. As channels, carriers, and provider APIs change, Sent absorbs the change, so your app doesn’t need constant rewrites.

The trade-off is the one you accept with any managed abstraction, whether a payments API or a container orchestrator: you give up direct control over per-channel mechanics in exchange for one consistent interface that hides provider complexity. For most applications that trade is worth making, because routing rules, compliance requirements, and provider integrations change faster than product code should. When you do need direct control, you can pin a channel explicitly in the send request.