ما الجديد في Orbit

**What changed** — When a reseller uploads a subaccount's brand logo during registration, the image lives in the reseller's own storage. A subaccount that inherits that logo from its parent previously could not re-issue a working signed link for it from its own account, so after the original link's expiry window the login screen and dashboard fell back to the default Devotel chrome. The system now detects genuinely inherited brand files on the white-label domain, copies them into the subaccount's own storage once, and serves a fresh signed link — so an inherited logo stays visible even as the original link ages, and the same fix applies to any inherited favicon or logomark.

**What changed** — When a visitor opened a reseller's white-label custom
domain, the sign-in and sign-up pages always rendered the default platform
logo instead of the brand logo the reseller uploaded while registering the
subaccount. The login pages can now read the domain's uploaded logo,
favicon, and brand colours before anyone has signed in, so the correct
branding appears on first paint.

**What changed** — In the **Inbox** view for a WhatsApp conversation, template messages now carry their Meta-authored buttons ("Copy code", "Visit site", "Call support", etc.) as clickable pills on the message bubble, alongside the rendered body text. Previously the bubble fell back to plain text and the buttons never surfaced — matching what the WhatsApp native client already showed.

The Messages → WhatsApp conversations thread showed a template message's body or template name, but swallowed the template's native buttons. Messages sent with a WhatsApp template that carries a BUTTONS component (a Copy-code OTP, Visit-site URL, or Call-support phone button) now render those buttons as a readable card under the message body, matching what the inbox side already presented. No template re-send is required — previously sent conversations now show their buttons when the thread is opened.

## What's new

The [Orbit blog](/blog) has a new explainer: **Meta's WhatsApp Pricing Shift: From Per-Conversation to Per-Message, Explained**. It lays out the change that moved across 2025-2026 — template messages now bill individually by category (marketing, utility, authentication) instead of one conversation window covering everything inside it — and where the free lanes stayed: customer-initiated service conversations and response windows opened by Click-to-WhatsApp ads or Facebook Page call-to-actions.

The post also covers what the shift does to a real bill — why template category hygiene now decides cost, why session-window checks double as spend checks, and how frequency caps act as a per-message spend ceiling — plus the template, window, and consent controls on Orbit that put those decisions in your hands.

**What changed** — On organizations with more than one connected WhatsApp Business Account, the account dropdown at the top of the WhatsApp channel page picked which account's conversations, templates, and analytics you were looking at — but the reply you typed in a conversation always sent from the org's *default* account, regardless of the dropdown. The inbound reply could arrive on one account and the outbound answer leave from another, splitting the thread across two sender identities and confusing recipients.

- **In-conversation replies (text and templates)** now route through the account selected in the dropdown, the same way the new-conversation compose dialog already did.
- **In-conversation Flow sends** route through the selected account too.
- **Single-account orgs are unaffected** — with one connected account, behaviour is unchanged.

The conversation header on the WhatsApp page shows which account a thread scope is for; what you see in the dropdown is now also what the send goes out on.

**What changed** — Inbound messages that arrive with no phone number but with a Meta username identifier (BSUID) were dropped at the very first routing gate and never surfaced in /en/inbox. Both the shared sandbox account's routing and the production inbound gate now accept those senders, and any remaining no-sender payload emits a warning + observable counter so an operator can see drops rather than discovering them from an empty Inbox.

The documentation gained a dedicated guide for [WhatsApp Flows](/docs/guides/whatsapp/whatsapp-flows), Meta's interactive in-app forms you send inside the 24-hour response window.

The guide covers the full lifecycle: define the flow JSON (screens, routing, terminal nodes), field the Meta category and status literals the API enforces, send the completed form via POST /api/v1/whatsapp/messages/send-flow or the dashboard Flow-send panel, receive the submission as message.received with its parsed answers and session correlation token, and watch where senders drop with the per-step funnel. It also explains the shared 80-per-minute convenience bucket on direct-send WhatsApp routes, and when a Flow wins over a catalog message, a template, or plain interactive buttons.

**What was wrong** — In a WhatsApp Flow's editor, a persistent error banner could be reporting a Meta validation error (such as *"FLOW_JSON_ERROR: Given Flow JSON version is not supported"*) while the **Validate** button still said the flow was fine — or only flagged content issues like a choice screen missing options. The two checks never disagreed on purpose: Validate simply wasn't looking at Meta's errors, which gave false confidence that a blocked flow was ready to publish.

**What's fixed** — **Validate** (and the editor's **Save** gate) now pair the local structural checks with the errors Meta has already reported for the flow. If Meta is still flagging the flow, Validate says so instead of passing it. No action is needed; the button and the banner now tell the same story.

The general [Send a campaign end-to-end](/guides/campaign-end-to-end) guide covers the channel-agnostic sequence, but its worked examples were SMS-shaped. WhatsApp campaigns have rules of their own: only approved templates send, the launch pre-flights the template's status and category against your synced registry, and read receipts and inbound replies arrive as webhook events SMS never emits.

The new [WhatsApp campaign launch playbook](/guides/whatsapp/campaign-launch-playbook) covers that delta step by step:

- Binding a template to a single-channel campaign via message_template, or to a specific step of an omnichannel fallback chain via whatsapp_template.
- The launch gates that matter on WhatsApp — local template sync, approved-only status checks, quality-rating auto-pause, and messaging-limit tiers.
- The callbacks to wire: message.read (a signal SMS lacks), message.failed with the Meta error when recipients get throttled, and message.received for replies in the 24-hour window.
- Discipline on read rates and Meta's per-user marketing-frequency capping, so engagement-quality audiences shape the send before Meta filters it for you.

**What changed** — When your organization has more than one WhatsApp Business Account connected, the WhatsApp messaging hub has an account picker in the header that scopes the page to one account. Opening the broadcast-list composer (the dialog that sends one approved template to up to 256 contacts) after switching that picker previously kept showing the approved templates of your default account, while nearby composes — New Conversation and the Marketing composer — already followed your choice — an especially confusing false surface, since selecting and sending a template owned by a different account fails at Meta with "Template name does not exist". The broadcast composer now scopes its approved-template list to the same account the picker chose, and the list refreshes the moment you switch accounts, consistent with the other template pickers on the page.

**What changed** — The in-product "What's new" drawer (the Headli/History icon in the header) used to load the same manifest for every user, so even if your profile language was set to Turkish/Arabic/German/French/Spanish, the titles and summaries came back English. The drawer now explicitly tells the changelog API your preferred language via Accept-Language, and the API answers with translated entries when they exist (with the canonical English fallback when a locale is missing). Fixes the QA re-report on change language / Changelog.

The [Resources](/resources) library added a foundational guide, [What is an omnichannel communications platform?](/resources/what-is-omnichannel-communications-platform), that answers the definitional "what is it" questions AI answer engines and buyers keep pulling up: the difference between omnichannel and multichannel, how the category composes CPaaS, CCaaS, and UCaaS, and what a buyer verifies before committing to one vendor's stack.

The guide is written answer-first — direct definition up top, FAQ section at the bottom — and points to the [omnichannel platform comparison](/omnichannel-comparison), the [omnichannel routing glossary entry](/glossary/omnichannel-routing), the [Orbit features hub](/features), and the [pay-as-you-go pricing](/pricing) page rather than a claim the rest of the site can't back. Outbound voice and SMS still terminate over Orbit's own wholesale softswitch, so the platform's termination quality and routing stay under Orbit's control.

**What changed** — In **Voice > Workforce > Scheduling > Forecast**, the What-if scenario lets you leave the arrival rate blank to use the latest forecast for the channel. When no forecast existed yet for that channel, the blank fallback silently resolved to zero traffic — and with zero traffic, any staffing level trivially predicts 100% service level, so the result showed **Meets target** with 0.00 Erlangs. That verdict was meaningless and could mislead a staffing decision.

Now, when a scenario resolves to zero traffic, the predicted service level is still shown but the verdict is **withheld** — the badge reads "No verdict — zero traffic" and a warning explains why. If the zero came from a missing forecast, the warning says to enter an arrival rate manually or run the forecaster first; if you typed a zero (or empty) arrival rate yourself, it asks for a non-zero value.

Scenarios with real traffic are unchanged — **Meets target** / **Below target** and the unstable-queue warning behave exactly as before.

**What changed** — When POST /api/v1/webhooks rejects a create with a 422, you previously had to work backwards from the raw error-codes table to find the fix. A new troubleshooting page in the docs walks each of the three creation-time error codes — endpoint-cap reached (you hold the maximum of ten endpoints, so delete a stale one or ask support for a raise), DNS-invalid (the hostname does not resolve publicly, usually a typo), and invalid URL (non-HTTPS scheme or a loopback/private address on the blocked list) — to its concrete fix path. The page closes with a GET /webhooks count check so you can confirm recovery before your integration calls again.

**What changed** — When a shared-line API call resolved which physical phone is holding the line's live call, the query handed the database a Java-array value as a plain scalar text instead of an explicit array literal, which the database rejected with a hard error. The Voice → Shared Lines dashboard page polls this endpoint to show which phone has the line engaged and to decide whether the Grab button is safe to offer, so both could fail in production. The query now builds its membership lists as proper SQL arrays, so the status poll and the Grab action succeed normally on every call.

Devotel Orbit's browser softphone terminates calls over the LiveKit media bridge rather than the Jambonz SIP webhook. Because the post-call final-charge step only ran on the Jambonz webhook, LiveKit-mediated calls completed, accrued minutes in the usage metrics, then never debited the wallet beyond the 1–2¢ pre-flight hold placed at dial time. The Jambonz finalize/refund helpers are now registered on the LiveKit end-of-call event (participant_left / room_finished), so positive-duration calls settle the correct final charge and zero-duration calls get their hold refunded — using the exact same helpers the SIP path uses, so the two paths stay in lock-step.

In Devotel Orbit's Live Calls panel, a connected call that the carrier never signalled a hangup for could appear as Answered with its call duration timer still ticking, even after both endpoints had physically dropped. The sweeper only watched pre-answer statuses, so it could never reclaim a row stuck in Answered.

The stuck-call sweeper now also walks the Answered bucket, keyed on the actual answer timestamp instead of the call's creation time, so genuinely long calls are not mistakenly terminated.

Reserving a shared desk for a future shift on the hot-desking screen lets you book one of the shared phones ahead of the walk-up sign-in period. After the reservation succeeded, the Device SIP username input kept the username you just reserved, while the time window and notes fields were cleared. That meant operators booking several desks in a row had to backspace the previous device name out of the field each time, and re-clicking "Reserve desk" without noticing could shoot a duplicate booking attempt at the same device.

The form now clears the Device SIP username together with the other fields as soon as the reservation is confirmed, so every fresh booking starts with a clean slate.

**What changed** — On Voice → Hot-desking, the "Device SIP username" field used to be a free-text box where agents had to type the exact SIP username (for example acme-shared-5F-2) from memory or copy-paste. It is now a searchable dropdown listing every active SIP credential in your workspace, showing the device label and username together. Picking a device also fills in the optional device label, so the session and audit trail carry a human-readable name.