sentdm Sent Routing Strategist
Routing is where the most expensive Sent misconceptions live. Two facts govern almost every decision:
- The
channelarray is a broadcast list, not a preference order.["whatsapp", "sms"]with two recipients creates four messages and four charges. There is nofallbackfield and no ordered-preference syntax. - Automatic routing is the fallback mechanism. Omit
channel, or send["sent"], and the platform selects a route, then reroutes across up to three distinct channel-and-provider pairs when a route-level failure occurs.
Decide the channel value
| Intent | Correct value | Reason |
|---|---|---|
| Reach the recipient however works best | omit channel or ["sent"] |
Enables route selection and reroute |
| Guarantee one specific channel | ["sms"], ["whatsapp"], or ["rcs"] |
Pinning restricts matching to that channel and never crosses channels |
| Deliberately deliver the same content on several channels | ["whatsapp", "sms"] |
Broadcast; expect one message and one charge per pair |
| "Try RCS, fall back to SMS" | omit channel or ["sent"] |
An ordered array would broadcast; automatic routing performs the fallback |
Any value outside sent, sms, whatsapp, and rcs returns 400. When a user asks for ordered fallback, name the misconception explicitly before writing code, because the failure mode is duplicate delivery and duplicate cost rather than an error.
What a pinned channel gives up
Pinning restricts route matching to the named channel. Rules without a channel constraint still match and resolve to the pinned channel, so pinning does not require channel-specific rules to exist. A pinned send never crosses to a different channel, though same-channel provider hops remain possible when a rule permits them. If no route exists on the pinned channel, the message ends FAILED with no route matched — it does not silently fall back.
Pin when a compliance, contractual, or content constraint requires a specific channel. Otherwise prefer automatic routing.
Reading the outcome
POST /v3/messages returns 202 with per-recipient message_id values. For automatic routing, the echoed per-recipient channel is not a resolved route and is never updated afterward. Resolve the truth from evidence:
| Question | Evidence |
|---|---|
| Which route was actually attempted | message.routed event, or channel on GET /v3/messages/{id} after routing |
| Did the recipient's device receive it | message.delivered |
| What sequence of routes was tried | GET /v3/messages/{id}/activities |
| Why did it stop | Terminal status plus channel value |
Terminal status interpretation
| Status | Meaning | Correct response |
|---|---|---|
FAILED |
A route attempt failed; automatic routing may still enqueue another attempt | Inspect the latest message state and activities before treating it as final |
FILTERED |
Policy gate — consent block or route denial | Never retry; a consent block is a compliance stop |
BLOCKED |
Account precondition — balance, onboarding quota, unapproved template | Fix the account condition, then send again |
SCHEDULED |
Parked by quiet-hours policy | Wait; it re-enters the pipeline automatically |
An outcome whose channel is auto means the message ended before any route was attempted. The causes are no matching route, invalid template parameters, a consent block, or an account precondition. Account preconditions do not reject the send request: it is accepted with 202 and the affected messages surface as BLOCKED.
Sent records internal send-time reason codes on the message for these cases, but does not return them in API responses or webhooks, so diagnosis relies on the status-and-channel combination plus the activity history. The mapping from observable evidence to root cause is tabulated in references/routing-diagnosis.md.
Reroute behavior
A failed route is retried only when the terminal failure signals a route or carrier problem another route might overcome: undeliverable by this route, provider service unavailable, provider timeout, or transport error. Every other failure stays FAILED.
Reroute reuses the same message_id and re-runs the pipeline, so message.queued and message.routed fire again, consent gates re-apply on every attempt, and already-attempted routes are excluded. The ceiling is three distinct channel-and-provider pairs across the initial send and all reroutes.
The WhatsApp-to-SMS behavior customers ask about is a specific case of this: a WhatsApp message accepted and then failed for a recipient-side reason reroutes and records a recipient-scoped rule that WhatsApp is not deliverable for that number, so subsequent automatic sends skip WhatsApp for that recipient. It requires automatic routing; a pinned WhatsApp send cannot produce it.
How automatic routing selects a route
Routes come from platform-maintained rules evaluated at send time against recipient attributes (country, number prefix, exact number, carrier, number type, ported state), sender, template attributes, channel, and whether the destination is international. Ordering is: exact-recipient rules first, then account-scoped before global, then match specificity, then rule priority, then longer number prefix, then the older rule. Inactive, deleted, expired, and below-threshold rules are excluded. Candidates whose template has an explicit non-approved review status on that channel are dropped, while a channel with no recorded review is not blocked. The first surviving candidate wins and the rest remain available as fallback routes.
There is no fixed channel preference order, so never promise "RCS first, then WhatsApp, then SMS." Read references/routing-model.md before making any claim about why a specific route was chosen.
Cost and volume consequences
Because broadcast multiplies messages by recipients, review any multi-channel array against expected spend before sending. A 1,000-recipient send with two channels is 2,000 messages. The per-request recipient ceiling is 1,000, and documented pacing pairs full batches with roughly one request per second to stay inside the 200-requests-per-minute budget.
RCS today carries text plus up to four suggestion chips, mapped from template buttons, and every outbound RCS message receives an appended STOP chip. Do not design an RCS-pinned flow that depends on rich cards, carousels, or media.
Boundaries
Use sent-messaging to execute a single send with confirmation, sent-two-way-messaging for consent and inbound keyword semantics, messaging-performance-analyzer for aggregate delivery-rate regressions, and sent-webhook-engineer for receiving and deduplicating the events this skill teaches you to read.