Black Friday and flash-sale sends fail for a reason that has nothing to do with the creative: the capacity math was never run. A campaign that sails through 5,000 contacts a day collapses at 50,000 because the API rate ceiling, the sender-side throughput cap, or a half-warmed number pool was never checked. This checklist walks the five gates a peak-season send must clear on Devotel Orbit — capacity math, fallback-safe creative, sender warm-up, tenant-owned guardrails, and the pre-go run-through — in the order you run them before the send wave starts.
1. Capacity math: per-second and per-minute throughput
The first gate is arithmetic, and two independent limits sit on SMS throughput — you have to clear both.
API-side request ceiling. Outbound SMS is rate-limited per tenant — 100 requests/minute by default on the send endpoint, shared across concurrent callers in your organization. Your peak wave must fit inside (requests/minute limit × 60 × batch size) per hour, or you raise the ceiling. The per-tenant cap is override-able in your organization's messaging settings, so a raised limit is a configuration decision you make before the event, not a support ticket you open during it. The rate-limits guide documents the per-channel table and the 429 retry behavior; per-channel defaults that matter at peak are SMS 100, WhatsApp 80, RCS 50 requests/minute — plan your chain against those numbers, not the aggregate.
Sender-side throughput. The second ceiling sits on the sender, not the API. US 10DLC throughput is a per-day, per-number segment cap set by your vetting tier; elsewhere it is whatever the destination's route supports per sender. When either ceiling binds, the lever is a sender pool: registered senders grouped under one sending identity, spreading volume across members on a round_robin, sticky, random, or geomatch strategy so per-sender throughput multiplies by pool size, and the pool health endpoint tells you which member is degrading before it becomes a deliverability problem.
Ground the numbers in your own telemetry. Do not plan against last year's nomination form. Pull last quarter's send volume by campaign and queue from the usage surfaces before you forecast — the campaign-analytics reports in Insights group every send by campaign or messaging-service queue for the 24h/7d/30d windows, which is exactly the baseline a peak forecast needs (the SMS click-through panel walkthrough shows the reading pattern, and the Insights hub's usage cards cover volume). Then check head-room: if your biggest projected hour is more than about 70% of the cleared ceiling, you have no retry margin — a 429 wave mid-send re-queues traffic on top of live traffic, and the wave thickens instead of draining.
Estimate segments, not messages. SMS segments bill per part — a UCS-2 flip or a brand-name emoji can double the segment count of every send (the SMS channel guide documents the 10-segment ceiling and encoding behavior), so run the estimate on the segment projection and multiply against the per-segment rate.
2. Fallback-safe creative selection
Peak season multiplies the failure count of every channel you use. Creative has to be authored so the primary channel's downgrade still reads complete — because the fallback hop carries plain text.
Define the chain at the organization level once: RCS → SMS, WhatsApp → SMS, or a longer multi-hop chain. The router applies it to every send path, and the send endpoint accepts no per-request fallback flag — one chain governs API sends, campaigns, journeys, and inbox replies identically. The consequence that matters for creative: an RCS rich card or a WhatsApp interactive template does not port to SMS. The SMS leg must carry the offer, the code, and the link as self-sufficient plain text, written during authoring — not discovered at send time when the degraded render ships.
The channel fallback capability matrix is the reference for which failure modes a chain can recover and which are terminal — a "Yes" in the retryable column means the message still has somewhere to land; a blocked recipient, a not-following relationship, or an opted-out contact is terminal, and no chain should route around it. The consent property matters more at peak volume: on Orbit the failed-over send re-runs the destination channel's opt-out check before it ships, so a contact who opted out of SMS is suppressed rather than re-contacted on the fallback leg — provided your per-channel opt-out posture is aligned. If the RCS agent says "reply STOP" while the SMS sender uses a different keyword, the downgrade changes the compliance posture mid-campaign; align the keywords before the wave, not after the first complaint.
3. Sender warm-up for short-pool numbers
New senders do not walk straight to full volume. US carriers build sender trust per number, and a brand-new 10DLC number that sends at full campaign volume on day one trips carrier filtering — messages submit (and bill) but drop before delivery.
Orbit gates outbound sends on every US 10DLC number while it warms: a daily cap that rises along a 15-day progression until the number graduates, enforced before submit so a cold number can only bill for what carriers will actually accept. The gate rejects over-cap sends with 429 WARMING_QUOTA_EXCEEDED rather than silently burning money at the carrier's filter layer — peak planning has to treat the warming state as a hard capacity input. Time your pool provisioning so every US member clears the ramp before the event window; a member still inside its warming phase adds its capped daily allowance, not its tier ceiling.
The full ramp — reading a number's warming_phase and daily cap, the per-day progression forecast, and how campaigns interplay with the gate — is in the number warming guide. For pools that mix warmed and warming members, the health endpoint returns the per-member tier, and the rotation scheduler auto-swaps a degrading sender for a warmed replacement.
4. Tenant-owned guardrails: cost ceilings, halt triggers, suppression
Peak guardrails are yours, not the platform's. The distinction is deliberate — Orbit ships the controls, the tenant sets the posture.
Cost ceilings. Set org-level spending alerts under Billing → Alerts — percentage of monthly budget, an exact month-to-date amount, daily spend, or a balance floor. Each rule can fire email/SMS notifications on trip and optionally auto-pause or block outbound when a threshold hits, so a runaway burn cannot stack another invoice while the ops channel is asleep. The dry-run endpoint lets you test a rule against today's metrics without stamping it. The full walkthrough is in spend caps, budget alerts, and auto-cutoff.
Immediate halt-trigger. For a send in flight, the halt lives in the campaign controls, not in your send code. The Settings → Campaigns page holds the per-campaign audience-cap override and the org-wide default quiet-hours window — both enforced server-side on every campaign send, so a mis-scoped audience or an out-of-window drip is refused before submit. The campaign limits guide documents the two cards and the API writes they map to.
Suppression lists. A duplicate at peak is not just a bad impression — it burns the frequency-cap slot, the segment, and the recipient's patience. Message suppression is a per-organization opt-in policy that silently skips an identical message body to the same contact on the same channel within a short window, enforced inside the send pipeline before frequency capping. It covers campaigns, flows, and batch API sends — the overlapping-campaign case that peak season manufactures at scale. The message suppression guide covers the policy fields; opt-outs and do-not-contact lists are the separate compliance surface, documented per channel.
5. The one-page pre-go checklist
Run these in order; each gate assumes the previous closed.
- Throughput forecasted. Peak-hour volume projected from your own campaign/queue analytics baseline; API ceiling checked against the per-channel table; sender-pool sizing confirmed per market.
- Rate head-room. Projected peak ≤ ~70% of computed ceiling — a
429wave mid-send compounds instead of draining; if you need head-room, raise the per-tenant ceiling in organization settings before the window. - Chain defined. Fallback chain configured at organization level (
RCS → SMS,WhatsApp → SMS, or longer); SMS leg authored complete as plain text; keywords aligned across chain channels. - Senders warmed. Every US 10DLC pool member checked against its
warming_phase; members still in ramp counted at capped daily allowance; health endpoint returning green on all members. - Guardrails armed. Billing alert rules with threshold values and enforcement actions saved; campaign audience cap and quiet-hours confirmed in Settings → Campaigns; message-suppression policy on for overlapping-campaign sends.
- Reversal ready. A named operator with the halt action (billing rule auto-pause or dashboard campaign halt) agreed before the wave, so a bad segment, a wrong audience, or a filtering spike stops the send in the first minutes, not the first hours.
Frequently asked questions
What is the difference between the API rate limit and sender-side throughput?
The API rate limit caps how many send requests your tenant can submit per minute — the default SMS ceiling is 100 requests/minute per organization, override-able in messaging settings. Sender-side throughput caps how many segments a given number can push per day — for US 10DLC it is set by your vetting tier. A send passes only when both ceilings clear; a sender pool raises the second, not the first.
Should every peak-season send end the fallback chain on SMS?
Almost always yes. SMS is the only channel that reaches any handset without an app installed, so it is the terminal hop in every sensible chain. Email and push work as fallback targets for some use cases, but neither matches SMS reach — the matrix above lays out which chains close on which channel.
How long does a new US 10DLC number take to warm?
The gate ramps along a roughly 15-day progression, rising day by day until the number graduates as warmed. Plan pool provisioning so every member clears the ramp before your event window — a warming member contributes its capped daily allowance, not its eventual tier ceiling.
Can a billing alert rule stop outbound traffic automatically?
Yes. A rule can be set to auto-pause or block outbound when its threshold trips, so a runaway burn cannot keep billing while you are offline. Rules are tenant-owned and opt-in; the dry-run endpoint lets you validate the rule against today's metrics before you arm it.
Is message suppression a substitute for opt-out lists?
No. Suppression blocks duplicate sends of an identical body to the same contact within a short window — it is a safety net over campaigns, flows, and retry logic. Opt-outs and do-not-contact are the consent surface and run as separate checks on every channel in the chain.
The takeaway
Peak-season capacity is a five-gate problem, not a hope-it-scales problem. Run the throughput math against your own analytics baseline and both ceilings; author creative so the SMS fallback leg reads complete; provision senders before the event so no member is still warming; arm the billing alerts, campaign limits, and suppression policy that are yours to set; and run the six-item checklist with a named operator holding the halt. Do those in order and the wave clears.
Published 2 October 2026.