What's new in Orbit

Watching a live broadcast used to mean the HLS viewer, with the WHEP URL only offered as a copy-paste row for external tools like OBS or VLC. WHEP now plays straight in the browser.

On a broadcast's live viewer page there's a new **HLS / WHEP toggle** — WHEP picks up the room's low-latency WHEP endpoint over a stock-browser WebRTC connection (plain HTTPS + SDP, the open WHEP draft) and drops the glass-to-glass delay to roughly a second, while HLS stays the default for maximum compatibility. The WHEP row under the player still lists the raw URL and now carries a **Play in browser** action that opens the player in a new tab.

For operators (and for viewers a customer links to directly) the new /voice/video/player/… page renders any WHEP playback URL on its own — no Orbit vendor SDK on either side, so a stock browser or an external WHEP client reaches the stream the same way. Playback failure states are first-class: a connection error renders an inline retry (HLS above remains the fallback), and a negotiated but idle endpoint shows a waiting-for-track state rather than a frozen black frame.

**What's new.** WhatsApp Flows built in the visual builder could be inspected at the funnel level, but there was no way to read each individual end-user's submission. A new authenticated API endpoint (GET /whatsapp/flows/:flowId/submissions) now lists one flow's submissions newest-first with pagination, per-submission status, and per-submission visibility:

- **The raw answers payload** — every screen the customer filled in, exactly as WhatsApp handed it back.
- **The submitter's resolved contact** — id, readable label, and phone when the submission could be tied to an existing contact.
- **A landed_in_cdp marker per row** — whether the submission has reached the customer's CDP profile, so event-triggered journeys and computed traits built on flows can be sanity-checked.
- **Pagination + a date window** (default trailing 90 days, up to 200 rows per page).

This backs the visual builder's Submissions dashboard surface — and for API consumers, it's a stable read over the same rows the WhatsApp completion webhook records.

When a customer finishes a WhatsApp Flow — a lead-capture form, a
self-service questionnaire, a survey built in the Flow visual editor — its
screen answers now land on that contact's profile as custom-field values,
not just in the conversation log. Segments, audiences, and automations you
build on custom fields can target these contacts right after they submit.

The write-back is additive, best-effort capture:

- Answers map to the custom fields you have defined under **Settings →
Custom Fields**. A Flow field id with no matching custom-field definition
is skipped, never invented as a new field.
- A blank answer (null or empty string) is ignored, so re-running a flow
with an optional field left empty will not wipe a value the contact set on
an earlier submission.
- One invalid answer (wrong type, out of range, disallowed option) no longer
blocks the whole submission — that field is skipped and everything else
still lands.

Define a custom field that matches your Flow's field ids (snake_case keys
like email, company_size) and the answer appears on the contact profile
the moment the Flow is completed.

Sixteen WFM surfaces shipped one tab at a time on the Devotel Orbit scheduling console — Assignments, Generate, Approval queue, Leave balances, Open shifts, Overtime, Voluntary time off, Shift roster, Activities, Forecast, Rebalancing, Capacity plan, Staffing optimizer, Shrinkage, Timesheets / Payroll, and Skills — but to answer the single daily question "how is today going" a supervisor still had to open four-plus tabs and mentally add them up. The new **Overview** tab closes that gap: the entire operating day in one glance, as it happens. Each chip drills one click into the tab that owns the number — required agent-hours → Forecast, pending requests → Approval queue, open postings → Open shifts — and because both sides count with the same rule, the chip and the drill-in can never disagree. Out-of-adherence agents color red the moment any are live, and a footnote flags events the adherence scorer hasn't judged yet so "adherent" can never silently imply the scorer is caught up. Scope follows the rest of the console: supervisors see org-wide roll-ups; agents see their own request queue.

Every Orbit webhook envelope already came in the canonical {id, type, created_at, data} shape, but a receiver integrating inbound traffic still had to register an endpoint per lifecycle event and branch on each concrete event type. events: ["normalized.inbound"] is now a member of the event allowlist — register once and the platform resolves it at dispatch time to the whole inbound family (inbound message received, delivered, failed, read, opt-out).

Every delivery from that family also carries a new data.normalized block — a small, documented envelope with event, kind, and the original payload body — so a receiver on one share name splits traffic on a closed enum (inbound / message / opt_out) instead of enumerating carrier vocabularies. Existing event subscriptions keep working unchanged; registrations that named one of the family's concrete events continue to match on that name, and non-family event types see a byte-identical envelope.

The webhook docs had the pieces scattered across four pages: the signature format on one, the delivery envelope and headers on another, retry timings on the overview, and the replay tooling on a fourth. An integrator starting from zero had to assemble the full picture themselves.

The new **Build your first webhook receiver** page under Webhooks closes that gap. It walks the whole loop in order: register an endpoint and copy the signing secret, serve a POST endpoint that keeps the raw request body, verify the HMAC signature (with full, copy-pasteable Node and Python receivers), deduplicate by event id, and route event types to handlers. It also lays out the retry schedule with exact timings, explains which response codes retry and which disable your endpoint, and covers the dead-letter queue and replay paths when something goes wrong. Linked now from the Webhooks overview and the API integration guide.

Subscribing to an event was always the easy half; the hard half was writing the handler without a sample body to work against. The webhook events catalog used to give you the event name and a one-line description, then send you elsewhere to find out what data actually carries. It now embeds a **Payload examples** section: complete delivery envelopes — the same id / type / created_at / data object your endpoint receives — for the families most integrations start with. Where a family has a terminal-failure event, the failure body sits next to the success body and shows the machine-readable failure field that family declares (error_code / error_message on message.failed, completion_reason on a failed campaign.completed, hangup_reason on call.failed, and so on), so your dispatch switch and your error branch are both coded from real wire shapes. The section regenerates from the same event catalog the subscription validator enforces, so a renames-and-forgets drift cannot ship it wrong; the full per-event-type field reference with notes stays on the webhook events reference page.

The Web SDK ships the chat widget, browser softphone, video rooms, the prebuilt verification UI, web push, in-app messages, feature flags, personalization, web analytics, and the CRM CTI bridge. What it intentionally does not ship is the management API surface (messaging, campaigns, contacts, billing, and friends): those need a secret key, which must never live in code you deliver to a visitor's browser. The README and the SDK overview page now spell out that split — and point you to the Node SDK on your server for everything the browser SDK leaves out — matching the scope notes the mobile SDKs already carried.

**What changed** — Configuring a GET/PUT /api/v1/agents/voice-eval/sampling-policy (enabled, a percent, an optional agent allowlist, and a golden set) persisted cleanly, but no completed production call ever reached the sampling gate, so a tenant that turned it on saw zero sampled runs. The call-completion path the voice agents funnel through now invokes the sampling decision for every naturally finished call — the same place conversation-ended events fire — and a sampled call schedules a voice-eval run against your configured golden set with no manual trigger.

**Why it matters** — Continuous sampling is the standing quality check on live traffic: a deterministic, repeatable percent of real calls is re-scored against your golden set long after launch. This fix completes that loop end to end, so the policy you set in the dashboard or API now produces the sampled runs it promised. Retries and duplicate teardowns never double-sample — only the first recorded completion of a call is eligible.

The Verification page carries a disabled "Enroll voice" button while the in-dashboard enrollment flow is still being built. Until now, the only explanation for why it was disabled — and that enrollment is available today via the REST API — lived in a hover tooltip. On touch devices there is no hover, so mobile users just saw a greyed-out button with no context. The explanation is now rendered as a small visible caption directly beneath the button, so the reason is readable on any device. The button label was also shortened to "Enroll voice."

The voice-biometrics enrollment wizard (the three-step dialog you use to enroll a voice for identity verification on the Verify dashboard: consent, phone pick, and enrollment status) called the translation system with the right keys, but the catalogs never carried them — so non-English dashboards always showed the hardcoded English copy. The strings are now in every locale Devotel Orbit ships, and the step titles, consent notice, phone-number form, status polling, and success/failure copy all render in the dashboard's active language.

**What's new.** The blog now carries the written announcement for voice data residency on Devotel Orbit, paired with the tenant configuration guide: which voice data classes stay in your pinned region, which controls are platform-provided versus tenant-owned, and a step-by-step EU deployment with recording residency.

- **Per-region voice media end to end:** call recordings, voicemail, live in-call media, and live call state each live in your region's own media servers, session store, and recording storage.
- **Tenant-owned controls:** region pinning in the dashboard or API, configurable retention windows, legal hold on individual recordings, and the option to write recordings into your own storage bucket.
- **No silent cross-region failover:** a pinned region is never substituted during a degradation — the guarantee EU and regulated buyers hold vendors to.
- **A worked EU example:** pin the workspace to eu, verify the resolution, set a 90-day retention window, and optionally bring your own recording bucket.

Read it on the blog: [Voice data residency on Devotel Orbit — the announcement, and how to configure it](/blog/voice-data-residency-announcement-2026).

Orbit Video already spoke HLS and DASH to viewers; getting a producer INTO a room or a sub-second playpath OUT of one previously assumed you were on the Orbit-running LiveKit stack. Both ends of that loop are now surfaced through the product:

- **Publish (WHIP)** — the "Add source" control on any room mints a WHIP endpoint plus a one-time bearer key. Point an OBS WHIP plugin, an FFmpeg ≥6 pipeline, or a browser studio at the URL and the room accepts the publish as an external producer — a normal participant tile to attendees.
- **Play (WHEP)** — the livestream response for a broadcasting room returns whep_url next to hls_url and dash_url. Copy it from the live viewer page (or pull it from the API) and paste it into any WHEP-capable player for ~1s glass-to-glass output that rides the same room ACL as the HLS path.

Because the promise is "standard protocols, no vendor SDK", the wire shape is now pinned: the API response, the dashboard's typed interface, and the viewer's copy row are held in lockstep by a contract test, so a future refactor can't silently drop the URL from one layer while the other two still advertise it.

Several video-room reads (minting a join token, redeeming a guest invite, toggling the waiting room, promoting lobby attendees, and polling the active-speaker list) trusted the stored room state without checking it first. If a room record ever drifted out of the expected set of states, those flows would have proceeded on a mis-read lifecycle and could have let someone join a room that had already closed. The state is now validated when the room is read, so an unrecognized value surfaces as an explicit error before any join or room action is allowed.

**What changed** — POST /api/v1/conversations/import-vcon accepts the same signed IETF vCon (Virtualized Conversations) container the export endpoint already produces, verifies its Orbit-HS256 HMAC against your workspace's shared export secret, and — only when the signature verifies — creates a new conversation row with its dialog turns (recovered channel, direction, timestamp, and the artifact's tamper-evident uuid stamped on each imported message so a handoff can be traced back to the file that brought it in). Each import mints a fresh thread rather than folding into an existing one, so a second tenant's thread never interleaves silently, and the 500-turn dialog is written in bounded batches inside one transaction (a malformed container rolls back atomically and surfaces as a clean 422).

**Why it matters** — The earlier export half made a thread portable out of Orbit; import closes the loop. A carrier, external AI system, or compliance archive can now return a signed thread as a real inbox conversation you can reply to, and because verification happens against your shared secret before any write, nobody can inject an artifact into your workspace without having been handed the export secret out-of-band.

**What changed** — Two actions now live in the conversation header of the unified inbox (and in the mobile actions drawer): **Export this thread** downloads the focused conversation as a signed IETF vCon container — the same portable, tamper-evident envelope the export API returns — and **Preview a vCon file** opens any .vcon.json file you've been given and shows what it actually contains: the subject, the parties, the dialog turns, and whether it carries a signature. Previewing never writes to your inbox; it's an inspection surface, not an import into conversation history.

**Why it matters** — The signed vCon export shipped earlier as an API, but surfaced nowhere in the dashboard. Now an agent can hand a thread to a carrier, an AI system, or a compliance archive as a standards-conformant, provable artifact without leaving the inbox — and when a vCon comes back the other way, you can verify exactly what it holds before you trust it. If your workspace has transcript PII masking enabled, the export still masks party addresses and message bodies before signing, so the artifact never carries cleartext PII you chose not to store.

Every form error surface (toasts and inline banners) renders a 422 validation rejection through the shared error formatter. That helper previously only uppercased the first character of the wrapped field name, so a camelCase wire field like forwardBusyToUsername surfaced verbatim as "ForwardbusyToUsername: …" — readable as a raw system string rather than a sentence. The helper now splits camel/Pascal-case (and snake/kebab separators) into words, so any future validation error names the field in plain language. This complements the earlier fix that made the voice-extension create form accept blank forwarding fields instead of rejecting them.

**What's new.** The blog now carries a guide on where USSD fits in the omnichannel stack, written for enterprise and telco-adjacent buyers evaluating the channel, and developer teams scoping an emerging-market deployment.

- **What USSD still solves:** zero-data reach on 2G coverage, feature-phone menu UX, and a synchronous two-way session — with a candid posture on the ~182-character screen cap and terminal-screen rules.
- **Typical buyer flows:** mobile money and balance checks, session-based IVR replacement, and network-initiated push sessions.
- **Unified reporting:** USSD callbacks land in the same workspace as your messaging channels, so channel analytics and contact history converge instead of fragmenting by channel.
- **FAQ:** covers USSD-versus-SMS selection, shortcode provisioning, channel handoff, and billing.

Read it on the blog: [Where USSD fits in the omnichannel stack in 2026](/blog/ussd-where-it-fits-2026).

**What's new.** Most "benefits of unified communications" pages stop at one login and one bill. This new post evaluates the question properly — what one account holding the phone system, the contact center, and the messaging API over a shared customer record actually changes in day-to-day operation — and works through where Devotel Orbit's converged platform lands against a stack of separate vendors.

- **Consent and compliance once, across every channel:** one quiet-hours and opt-out rule set for SMS, the outbound dialer, and voice, instead of a per-vendor implementation to audit.
- **Routing with context attached:** the customer's conversation history, sentiment, and CRM notes travel into routing and the AI-assist layer before the phone rings, rather than being re-collected on every call.
- **One vendor, one bill, one diagnostic ceiling:** the five-admin-panel delivery investigation collapses to a single account's logs.
- **One number inventory, one network:** voice, SMS, and WhatsApp run on numbers from one inventory, with outbound terminating over the same carrier path across every channel.

Read it on the blog: [What Unified Communication Platforms Actually Buy a Business](/blog/unified-communication-platforms-benefits-2026).

**What's new** — [Best Twilio alternatives for voice, SMS, and AI agents](/compare/best/twilio-alternatives-voice-sms-ai-agents-2026) now answers the pricing-model question head-on. A new FAQ, "Which Twilio alternative offers the most flexible pricing model for voice, SMS, and AI agents?", compares the pricing models rather than just the rates: Orbit's published pay-as-you-go per-destination rates with AI voice agents included on the same bill, against per-product assembly elsewhere.

**Why it matters** — The guide already compared features, carrier-of-record ownership, integration effort, and local rates including the United Kingdom. The pricing-model question — pure usage billing versus a stack of separately assembled product contracts — was only answered indirectly. It now gets a direct, quotable answer, and every vendor in the ranked list links to its official site so the round-up parses cleanly in search and answer engines.