What's new in Orbit

Several glossary entries defined a term in its generic telecom-industry sense without the Orbit-specific behavior that makes the term useful inside this platform. The entries now keep the one-line industry definition and add an Orbit paragraph below it, matching the depth the rest of the glossary already carries.

- **Contact** — the identity-resolution and segments surface: repeated identifiers fold onto one contact record, and audience segments are built and refreshed through the contacts segments endpoint.
- **Cursor-Based Pagination** — the messages list returns an opaque next_cursor whose value is a keyset token, so paging through a growing inbox never reskips or skips a row.
- **Fallback Channel** — a notify send walks an ordered channel chain, returning the binding that queued as active, the bindings rejected synchronously as skipped, and the pending hops as fallback_chain, with a cumulative cost cap that drops later hops rather than advertising a channel that will never be attempted.
- **GSM-7** — a single non-GSM-7 character forces the whole body into UCS-2 and re-encodes it, dropping the per-segment budget from 160 to 70 characters and changing the billable segment count the message API returns.
- **Panic Button** — the softphone label for the agent distress alert, distinct from the API and audit vocabulary ("distress"), including that a press forces recording on and persists a durable, audited incident.

Find the updated entries under Reference → Glossary in the docs.

The WhatsApp documentation previously spread the WABA lifecycle across the
channel page, four guides, and three troubleshooting pages, with no single
anchor describing a WABA as a thing on the platform. A new Concepts page now
holds that story end to end:

- **Connect** — what Embedded Signup hands back (the Graph access token, WABA
id, phone-number id, and webhook subscription) and how the connection is
stored and scoped to your organization.
- **Register** — the connected → registered → live state machine, the
registered_at stamp that separates "connected" from "can send," and the
422 CHANNEL_NOT_CONFIGURED a send against an unregistered connection
receives.
- **The 2026-10-08 retirement** — the shared Devotel test account that used to
carry sends before your own WABA was approved was removed; your own WABA is
now the only send path, with no admin fallback.
- **Migrate** — what a move from another Business Solution Provider carries
(WABA id, phone numbers, quality rating, messaging-limit tier, approved
templates) and what it does not (message history, prior template analytics).
- **Number attach and reassignment** — how the phone number, not the WABA, is
the send-time binding, and why one WABA can carry numbers with divergent
quality ratings.
- **Disconnect and delete** — that a disconnect clears credentials but leaves
history in your tenant schema, and a delete is the terminal teardown.
- **Conversation pricing** — where the per-conversation, 24-hour-window billing
model hooks in, with the pointers into the billing pages for the detail.

The page is linked from the Concepts hub and the Concepts → Messaging & Routing
navigation group.

When the WhatsApp template library browse returns a 422 error, the
troubleshooting page now breaks down the upstream status codes into
recoverable and terminal classes. A 429 rate-limit response from Meta
no longer looks like an auth failure — the page explains exponential
backoff, safe manual retries (the browse is read-only), and why
reconnecting is the wrong move for a rate limit. The 400 row now
covers unsupported request filters (a Meta app version mismatch, not a
disconnected WABA), and a new "Rate limits and pagination" section
distinguishes first-page failures from mid-pagination failures so you
know when to retry versus when to reconnect. The page also links into
the full WABA setup guide for the reconnect flow.

When you add a template to your WhatsApp Business Account from Meta's Template Library, the create can be rejected — most often because the template name is already taken on that account, or because Meta rejected the button inputs. Previously the dialog showed no sign of the failure: the spinner stopped, the dialog stayed open, and no message appeared, so it was impossible to tell a failed attempt apart from one still in progress and you had no way to know what to change.

The adoption dialog now shows the reason for the failure inside the dialog, in your language, the moment the create is rejected — with the same friendly fallbacks the rest of the dashboard already uses for opaque errors. Edit the name or inputs and retry; the message clears as soon as you try again.

When you add a Meta Template Library template to your WhatsApp account and the request is rejected, the "Add to your WhatsApp account" dialog now keeps the rejection reason on screen instead of relying on a temporary notification that disappears. Correct the template name (the most common cause is a name you already use) and press "Add template" again — the dialog stays open and the retry goes through immediately.

A CTA-URL button puts a labelled link button ("Track order", "View invoice") below a free-form WhatsApp message. Because it ships inside the 24-hour customer-service window, it sends immediately — no Meta template review — and the label and destination are yours to choose per send. Until now the API supported it without a companion guide.

The new guide, **WhatsApp CTA-URL tap-to-open link buttons**, covers the send request on POST /api/v1/whatsapp/messages/send-interactive, how the button's URL is rewritten to a tracked short link so every tap arrives as a short_link.click webhook tied to the originating message, the HTTPS and honest-labeling rules the button has to follow, and a side-by-side comparison with template URL buttons for deciding which fits a given send.

Find it in the docs under Guides → WhatsApp, and linked from the WhatsApp channel overview.

On **Voice → Scheduling → Rebalancing**, running a recommendation previously
gave no on-page feedback: the button disabled and the page sat idle until
the result appeared, and if the recommendation could not be computed the
only signal was a disappearing toast notification.

The tab now shows a "Computing recommendations" state while the
recommendation runs. If it can't compute — for example because of a
connection problem — the page explains that recommendations are unavailable
and lets you dismiss the message and adjust your staffing inputs before
trying again.

A voice call recording moves through capture, storage, retention, and deletion — and until now, each of those operations was documented separately. The new **Voice call recording lifecycle** runbook ties them together in one walkthrough:

- **Start recording** — consent posture, channel announcement, and manual versus automatic arming.
- **Retention windows** — set per-domain retention so recordings are deleted automatically after a configurable number of days.
- **BYO storage** — deliver finalized audio to your own Google Cloud Storage bucket and validate the egress stamp.
- **Replay** — signed playback URLs and the dashboard player.
- **Legal hold** — exempt specific recordings from the retention sweep for litigation or regulatory preservation.
- **Purge** — delete a recording and all its artifacts to comply with a DSAR or court order, including guidance on removing BYO bucket copies.
- **Audit trail** — trace the full lifecycle in the audit log export and through the audit webhook stream.
- **Common pitfalls** — stuck recordings, egress signature mismatches, retention-hold ordering traps, and HIPAA flooring.

Find it in the docs under Guides → Voice call recording lifecycle, and linked from the recording consent and legal hold pages.

A guest who joins a video room from an invite link can post to the room chat through the POST /api/v1/video/rooms/:id/chat route — but until now, when that send refused, nothing in the docs told you why or what to do next.

Three new FAQ entries close the gap. **Why did my guest's video chat message bounce with 403 VIDEO_CHAT_GUEST_FORBIDDEN?** explains the identity check behind the refusal — an anonymous guest must send with the join invite token from the room's link, and a guest still held in the waiting-room lobby cannot post until the host admits them — and the recovery path (re-join through the invite link, then have the host admit). **Why can't my guest see the room chat surface at all?** clarifies that guest chat is an API surface, not a widget toggle: the prebuilt embed ships no chat panel, so you render your own and call the route with the guest's join_token and livekit_token. **Is there a chat policy the room enforces on guests?** covers the per-room chat content policy that screens host and guest sends alike, with the block/flag/log modes and the refusal codes that tell a policy block apart from an identity refusal. All three are linked from the troubleshooting hub's Video section.

The TCPA rules for how a recipient gets off your contact list changed in 2025. The FCC's revocation-of-consent order, in effect since April 2025, accepts a revocation in any reasonable form: a texted unsubscribe, a "leave me alone" reply, or words spoken on a call, honored within 10 business days and reaching across channels, not just the one the request arrived on. Around the same time, the Eleventh Circuit vacated the FCC's one-to-one consent order before it took effect, so consent scope is still judged by the consent language you captured.

The new guide, [TCPA Reasonable Revocation (2025)](https://orbit.devotel.io/compliance/tcpa-reasonable-revocation-2025), sits in the docs under Compliance next to the opt-out keyword alias tables, and walks through what each change asks of your program: where Orbit already honors the STOP keyword vocabulary automatically, why a reply that matches no keyword is a revocation you still have to honor and how to run that review path, which scope to record when a revocation arrives by phone call or email, fitting the 10-business-day window inside your own processing clock, and what a defensible 2025-era revocation record looks like in your consent ledger and evidence exports.

As with the rest of the compliance section, every section states the same note: the orders' current status and what they require of your traffic is a question for your qualified counsel.

The confirmed-consent handshake page explained what double opt-in is and the API calls behind it, but the day-to-day loop lived in three places at once: an organization setting, a consent prompt sent in place of your first marketing SMS, and a held-send state until the contact replies YES. The new guide ties those pieces together in one walkthrough.

It covers when a US or Canadian marketing program should require confirmed consent and when a single opt-in regime does not, the four consent states a contact moves through (no record, awaiting YES, confirmed, opted out) and how each reads in your consent ledger, enabling the flow from Settings or the API, the confirmation prompt copy that ships and the branding fields that customize it, what a held marketing send returns and why it is not a delivery failure, how an inbound YES, START, or SUBSCRIBE in any supported language unblocks the contact, and where to read the prompt-and-reply evidence back for audits.

Find it under **Docs → Guides → Enable and Operate the SMS Double Opt-In Flow**, next to the consent handshake reference.

The Devotel Orbit Settings guide now explains how organization controls fit together, where to change common policies, and which roles can read or write each family. It also distinguishes similar controls such as consent, keyword replies, duplicate-message suppression, and retention, so you can choose the right console before changing your setup.

**What changed** — The SDK index at docs.orbit.devotel.io/sdks now opens with a
"Map the SDK surface" section. It is a single table across all twelve SDKs:
the install command, a one-line quick start (create the client, make one
call), the authentication model (API key header versus publishable key),
the pagination convention (cursor, not offset), the error envelope (typed
exception classes on the typed SDKs versus a plain error code on the raw
REST surface), realtime support (server-sent events for the client SDKs,
request or response only on the server SDKs, webhook delivery to your
backend), and the live base URL. Each row links to that SDK's own reference
page. Below the table, a "Start with…" pick-list routes you to the right SDK
by capability, and a "Mobile parity" note states which platform owns the
Swift, Android, and React Native surface and where drift between them is
intentional.

**Why** — The hub was a reference-style listing of per-language pages. To
compare how two SDKs differed on authentication, paging, or streaming you
had to open each page. The new table puts the comparison surface one scroll
from the top, before the per-language detail fans out.

**What changed** — The blog now carries a buyer-side explainer on Apple's iOS RCS support and what it changed for business messaging in 2026: the dated Apple-side state (iOS 18 in September 2024, carrier enablement through 2025–2026, Apple Messages for Business on RCS where carriers enabled it), an honest "carrier and region dependent" read on what an iPhone recipient sees versus an Android recipient, and the capability checklist to demand — per-recipient capability probing, rich-card delivery, and a tenant-owned fallback chain to SMS.

The post ties that checklist to the capabilities Devotel Orbit ships on the RCS API — per-recipient capability probing with a 24-hour cache, rich cards and carousels in one request, verified sender branding, and an org-level fallback chain to SMS — and closes with an FAQ on opt-in, template approval, and per-message pricing posture.

The post is live at [Apple's RCS Support Changed Business Messaging in 2026 — What Buyers Should Demand](/blog/rcs-business-messaging-ios-reach-2026).

The Quiet Hours FAQ already covered the org gate, the campaign fallback, and the preview one layer at a time. The questions that escalate asked about two layers at once — a campaign that carries its own window and inherits the fallback, a voice send that clears the campaign path but trips the federal guard, a contact whose CRM timezone disagrees with the area-code resolution.

A new **Layered composition** section on the FAQ answers nine of those cross-layer questions: which gates run on a given send (with a flow diagram separating 1:1 ad-hoc traffic from the campaign path), the yes-and answer when a dual-qualified campaign was blocked and how to tell which layer wrote the audit entry, the audit-entry lookup keys for proving which window applied to a specific send, how to set one posture per campaign group instead of per campaign row, how a source-of-truth timezone overrides the area-code resolution, and how next_allowed_at handles DST, weekends, and the federal guard composing on top of the tenant-owned layers. Find it in the docs under Compliance → Quiet Hours FAQ.

The **Push broadcasts: setup and pre-send caps** guide described every endpoint in prose but showed almost none of them. Setting up a broadcast meant hopping between the guide and the API reference to piece together the real call.

Each section now carries the request and the response you see back, copy-pasteable: the wildcard send on POST /api/v1/push/send with its 201 per-device verdicts, the BROADCAST_TOO_LARGE 422 and CHANNEL_RATE_LIMITED 429 refusal envelopes — including the Retry-After and rate-limit headers the 429 returns — the settings calls that raise your per-minute push envelope, device-token registration with the idempotent upsert response, muting a device with PATCH, and paging the delivery log with its cursor parameter.

Find it in the docs under Guides → Push broadcasts.

The public-surface endpoints are what you integrate into your own marketing site or support portal: the hosted idea board (GET/POST /public/ideas, votes, comments), the community Q&A (/public/community/questions and answers), the published pages catalog (/public/content/pages), and the signed-share links for recordings, transcripts, and embeddable analytics dashboards.

The [Public API reference](/api-reference/endpoints/public) now documents what those endpoints return:

- **Idea board** — the idea record with its lifecycle status (under_review, planned, in_progress, shipped, declined), vote and comment counts, and the three-column roadmap view.
- **Community Q&A** — question and answer records, the accepted-answer flag, and the { voted, vote_count } acknowledgment every vote endpoint returns (votes are idempotent per visitor, so retrying is safe).
- **Pages catalog** — the cursor-paginated list with nextCursor for walking the published corpus.
- **Signed-share links** — which endpoints answer with a rendered HTML page (shared recordings, protected transcripts, subscription confirmations) and which answer with JSON, so you embed or redirect accordingly.

Request samples were corrected alongside: path IDs now use the document ID formats the endpoints accept (e.g. fi_… for ideas, cq_…/ca_… for community threads), so a copy-pasted call returns the documented response instead of a validation error.

The persistent video rooms guide walked through create, re-open, and embed, but left the operator questions a drop-in "video call us" button raises unanswered: how many persistent rooms a tenant may hold, whether a link you sent last month still lands in the same room, whether each re-open bills as a new room, and how recording retention interacts with a room that empties and re-opens all day.

The guide now answers each one. A persistent room has no per-tenant count cap, the join URL stays stable across re-opens, re-opening is billed as participant minutes per session rather than a per-activation fee, and each session the room produces inherits the same retention window as any other video session.

SMS pricing in Devotel Orbit resolves per operator, not per country: a send is attributed to the mobile network that carries it, and the rate for that network is what you are billed. The new [Per-operator SMS rates](/guides/billing-mccmnc-per-operator-rates) guide documents that model end to end, alongside the [existing overrides reference](/guides/billing-mccmnc-overrides).

What the guide covers:

- **How a send resolves its operator** — from the destination's MCC/MNC on the send path and from the dial-code deck before the network lookup answers, and how voice resolves the same way by longest dial-code prefix.
- **The rate chain, tier by tier** — your per-network override first, then the published per-operator rate, then your country row, then the platform defaults — and what each tier bills when a row is missing.
- **Bulk maintenance by CSV** — the exact template columns for Billing → MCCMNC Overrides, row-by-row upsert behavior, and the export → tweak → re-import round trip.
- **Diagnosis** — read the message record and the SMS rates card, then locate the missing row when a send priced on the wrong tier.
- **A worked example** — Iran's MCI network, whose real cost of 0.2099 was billed at the 0.2757 country row: a 31% overcharge until the operator row existed.

Every change made on the MCCMNC Overrides page carries into the pricing change history, and the guide shows where to read it. The guide is live in the docs under Billing.

The On-Call API computes who gets paged and when; your system drives the incident. Until now the runbook stopped at that design, and the production loop was left as an exercise.

The **On-call roster & escalation policy runbook** now carries the driver too: a Postgres schema for the incident snapshot, a Cloud Tasks scheduler that calls tick at each next_tick_at, the page fan-out over the Messages API (POST /api/v1/messages/sms for SMS pages, POST /api/v1/voice/calls for the voice fallback), and the ack receiver that halts escalation. New sections cover races and idempotency, delivery webhooks that tell "the carrier failed to deliver" from "the pager never acked," a swap-in fallback for send-side failures, and the quiet-hours and opt-out choices pages inherit from your senders.

It closes with the payments Sev-1 policy driven end to end: four pages on the timeline, an SMS that fails at the carrier and swaps to voice, and an escalation that halts on ack or surfaces as exhausted.