What's new in Orbit

A phone number can be the verified WhatsApp test number for one workspace at a time, and until now the 409 that says so arrived without anywhere to look it up. The new [WhatsApp test number held by another workspace](/troubleshooting/whatsapp-test-phone-occupied) runbook covers the refusal end to end, and is linked from the WhatsApp section of the [troubleshooting hub](/reference/troubleshooting-hub) and from the [Error Code Reference](/reference/error-codes).

- **What the refusal means** — TEST_PHONE_REGISTERED_IN_OTHER_WORKSPACE on POST /api/v1/whatsapp/test-account/send-otp (and verify-otp) means the number is already bound to another workspace's test account. Repeating the request changes nothing; it is a claim check, not a cooldown.
- **Three ways through** — register a different number that can receive the verification code; have an owner of the holding workspace release the number from its test account; or, when the claim is stale or unrecognized, open a support ticket with the request_id from the refusal.
- **Distinct from WABA errors** — the test account is the shared sandbox you can build against before connecting your own WhatsApp Business Account. Connection failures on your own WABA speak NOT_CONNECTED or CONNECTION_INVALID and keep their own runbooks.

No behavior changed; this documents the shipped test-account registration gate.

Until now, a Slack install that bounced back without a Connected workspace, or a channel selector that flipped to Disconnected after connecting, left you guessing which step failed and whether to retry, restart the install, or reconnect the workspace.

The new [Slack connection and sync failures](/docs/troubleshooting/slack-connect-and-sync) runbook separates the two steps that fail differently — the OAuth install callback and the day-to-day channel read — and walks each error code to its fix:

- **A rejected code exchange** — the one-time code was already used, expired, or mismatched the install request. The fix is to re-initiate the install from the integrations card, never to replay the callback URL.
- **A failed code exchange** — Slack's token endpoint was down or returned a server error. Transient: wait ~30 seconds and start the install again, and escalate with the request id if it persists.
- **An unreadable stored bot token** — the connection reverts to Disconnected shortly after Connected. The fix is to disconnect and reconnect the Slack integration, which replaces the stored credential.

The page also covers the two missteps that make these codes worse — re-clicking the install button while a callback tab is still open, and expecting a pasted bot token to work in an OAuth-only integration — plus the exact details to send support when a clean reconnect still fails. The [Slack channel page](/docs/channels/slack) and the [Slack onboarding guide](/docs/guides/slack-onboarding) both link to the runbook from their error sections, and it is listed under Channels and integrations in the troubleshooting hub.

A click-to-call request returns the SIP_CREDENTIAL_NOT_REGISTERED
refusal when the phone registered to your SIP credential has not checked
in within the registration window. The new troubleshooting guide walks
you through it end to end:

- **Read the refusal.** The response now has a home that explains
details.last_register_at and details.stale_threshold_seconds, so
you can see exactly when your device last registered and how old a
registration may be before the next dial is refused.
- **Fix the device, client by client.** A per-client checklist for Bria,
Linphone, and Zoiper covers the account register toggle, the
credential username and password, the SIP server address, the
transport, and the NAT and firewall causes that keep a client
unregistered.
- **Skip the dead ends.** The guide calls out the fixes that do not
apply, so you do not rotate an API key or re-create a credential for a
refusal that is about the phone's registration.

The guide is linked from the troubleshooting hub's voice section and
from the SIP_CREDENTIAL_NOT_REGISTERED row in the error-code
reference.

A failed message send used to mean checking four developer surfaces and
knowing on your own which one to trust first: Request Logs for the HTTP
shape, Delivery Logs for the message lifecycle, API analytics for the
aggregates, and webhook deliveries for your event consumers. The new
guide [Where to look first when a message send
fails](guides/diagnose-a-failed-send) gives that order for you. A
decision table maps five failure shapes to the pane to open first, the
filter that isolates them, and what a healthy result looks like on each.
Two worked examples carry a send end to end through the console: an SMS
that returns 202 and never leaves queued, and a WhatsApp template
rejection, including the difference between a refusal at send time and a
provider rejection after acceptance. Per-channel notes cover WhatsApp
template approvals, SMS carrier filtering, RCS fallback to SMS, and
missing email DNS records, and a closing section lists exactly which ids
and timestamps to capture before escalating to support. The guide sits
next to the Delivery Logs guide in the docs navigation, mirroring the
existing triage guide for outbound voice calls.

Audience activations that require a second sign-off could refuse your
submit or decision call with codes like "approval already decided" or
"the batch changed since approval", and the docs offered no decoder for
them. A new runbook, [Activation approval state
errors](troubleshooting/activation-approvals), covers the full approval
lifecycle and each refusal in turn: an approval that does not exist or
rolled off the queue, one already consumed or rejected, a decision that
raced an earlier one, a decision attempted by the requester themselves, a
batch whose membership drifted after approval, and an approval presented
for a different destination or operation. Each code pairs with the
operator move that resolves it, the envelope examples to capture when
escalating, and the two attempts that never pay off: replaying a consumed
approval id, and editing an activation in place after a batch change. The
same codes now also appear in the error code reference and the FAQ.

The global search API reference previously sketched the response envelope without a populated example, so there was no shape to code a palette or telemetry integration against. The page now opens with a complete round trip: a scoped two-pillar query and the 200 it returns, with results[] and by_pillar entries carrying id, title, href, and score, the per-pillar counts, and the partial array a client renders as a discreet per-pillar failure hint. A short note explains static_match_count — send the number of client-side shortcuts you rendered so a query that matched only static entries is never recorded as zero-result.

The integrations reference gains the Intercom connect flow on the same worked-sample pattern: start the OAuth install, hand the authorization URL to a workspace admin, read back the connected workspace and its subscribed topics, then confirm freshness with the status read-back and force a re-pull after a large import.

When a WhatsApp message is sent through a shared business account, Devotel Orbit quotes the cost up front and reconciles the wallet once Meta reports the final pricing of the conversation — refunding messages Meta marks free and adjusting the charge when the final category differs from the quoted one.

That reconciliation was failing on every eligible message before it could touch the wallet, so refunds and adjustments the reconciliation exists to perform never landed. The fix reads the charge actually recorded on the message and completes the refund or reprice from that figure; when no charge was recorded (the free-tier case), the wallet is left untouched instead of being credited an estimated amount.

The existing workforce-management guide walks the WFM loop as a
concept-to-API narrative and assumed you already knew the loop.
[Publish your first weekly roster](guides/voice-scheduling-first-roster)
assumes you don't: a 90-minute, console-only session for a center with a
dozen agents and two queues. It opens with a caption tour that maps every
Scheduling tab to the question it answers, then works the setup in order,
shift templates, activity segments (break, lunch, coaching), and the
skills registry that decides who is eligible for each shift, before
running schedule generation for the coming week and reading the coverage
preview before you commit. The four planning tabs follow in the order you
will actually use them: interval requirements in the forecast, dedicated
vs blended staffing for your two queues in the optimizer, headcount vs
demand in the capacity plan, and the shrinkage multiplier. Day-two
operations close the session: publish an open shift for a sick agent,
approve a swap once the counterparty accepts, and read intraday adherence
exceptions. The console story ends where the API story begins, with
bridges to the workflow guide and the WFM endpoint reference.

The voice preferences reference previously showed its two worked API calls in cURL and TypeScript only. It now carries both calls in all six SDK languages, in the same tab order as the rest of the API reference, so you can copy the read or the write straight into your stack.

Each language uses its SDK's generic request escape hatch, so auth and the data / meta envelope behave exactly like the typed resources. The write path also shows the labelled 403 response a role-gated call returns, and the response examples now include the caller_scope field alongside the forwarding rule.

The existing desk-phone guides covered the console flow through the
register step, but a 200-handset install needs more than the CSV:
watching phones come online and recovering the failure subset. The new
[fleet rollout guide](/guides/voice-desk-phone-fleet-rollout) is the
runbook for that half of the job:

1. **Pre-staging** — SKUs, the deduped MAC export, extension ranges
created ahead of time, and the network prerequisites (TLS egress,
PoE, SIP-ALG off) with a worked 200-row CSV template.
2. **Bulk registration and pairing** — what the registered / failed /
skipped counts mean, how the hourly window shapes uploads, and when
to pair in the single create versus pairing the batch after import.
3. **Zero-touch day** — the MAC-to-URL record each vendor redirect
service (Polycom ZTP, Yealink RPS, Cisco EDOS, Grandstream GDMS)
carries, and the two dashboard signals that show a phone came
online.
4. **Verify and recover** — a cursor-paginated devices-API check that
reports paired / fetched / active per row, the per-reading recovery
loop, and a failure table for duplicates, foreign MACs, and spent
provisioning URLs.

The guide cross-links
[Extensions and desk phones](/guides/extensions-and-desk-phones) and
[Desk phones: zero-touch provisioning](/guides/voice-desk-phone-provisioning)
for the single-phone flows, and closes with a facilities handoff the
install day can run without you in the room.

Enrolling voiceprints put tenants inside biometric-privacy law, but the
compliance docs only touched BIPA and biometrics in passing. A new
posture page, [Voice biometrics privacy posture](compliance/voice-biometrics-bipa-posture),
covers the regimes in one place: BIPA's written informed consent,
retention schedule, and sale prohibition; CUBI and MHMDA notice,
consent, and destruction duties; the EU AI Act Article 5 prohibitions
set against consented one-to-one speaker authentication; and GDPR
Article 9 special-category framing. Every obligation is paired with the
tenant-owned control that satisfies it, from the verbatim consent
record captured at enrollment to hard delete and the DSAR erasure
certificate as destruction evidence, with a short FAQ on opt-in
support, spoof-score retention, scheduled destruction, and the PHI
boundary.

A persistent video room stays joinable indefinitely, but two closes can still land it in ended, and neither was named anywhere a customer would find them. The [video room lifecycle](/troubleshooting/video-room-lifecycle) runbook now opens a section on exactly that question, and the [troubleshooting hub](/reference/troubleshooting-hub) links it from its Video accordion.

- **What persistent means** — the room's expires_at is set years ahead, so the default 4-hour auto-end never fires, and when the room empties and closes, the next join re-opens it with its guest invites intact.
- **What it does not mean** — a live room that stays empty for ten minutes still closes (re-openably: the next join brings it back), and ending a room from the dashboard or API is final for every room, persistent included.
- **Reading an ended persistent room** — video.room.ended carries the answer: end_reason: room_finished is the re-openable empty-room close, while operator_end is an explicit End (or the 4-hour expiry path on a non-persistent room).

No behavior changed; this documents the shipped video room lifecycle.

The search box above the Recent Verifications table on the Verify page
used to match only the recipient, config name, channel, and status.
Pasting a verification ID — the one shown in a webhook payload, an API
response, or copied from a row — returned "No results", leaving you to
scan the list by eye.

The same search now also matches verification IDs, case-insensitively, in
both the table's search box and the filter bar above it. The placeholder
text now mentions ID, so what you can search for is visible at a glance.

When you open a verification in Recent Verifications, the Status timeline lists the events of its lifecycle. Until now, a verification that simply ran out of time left no footprint there: expiry was only recorded if someone submitted a code check after the window had already closed, so a verification that lapsed and was later cancelled looked as if it had been cancelled while still live.

The timeline now derives the expiry from the verification's validity window and records it as an Expired entry with the exact timestamp, positioned before any later event such as a cancellation. Verifications cancelled while their window was still open keep their existing history unchanged, and verified verifications continue to show Created and Verified as before.

On the Verify page, opening a verification whose validity window had
passed and pressing Resend code showed a "Verification has expired"
error, but the message list kept showing the old pending status until
the page was manually refreshed. The stored record was already marked
expired at that point — only the on-screen copy was stale.

The Verify list and the details drawer now refresh after any resend or
code-check error, so the status shown in the drawer, in the list, and in
the stored record always agree, with no refresh needed.

The menu item that opens the verification hub was labelled "Verify" —
the lone verb among otherwise noun-based labels like Inbox, Channels,
and Numbers. It now reads "Verification", in step with the rest of the
menu and with the "Recent Verifications" heading on the page itself.

The label appears translated in every supported language, and the
hub's address is unchanged, so bookmarks and saved links to it keep
working exactly as before.

When a verification was cancelled, its webhook identified the verification but did not include the message text associated with it. Integrations had to make a separate API request to understand which message the event referred to.

The verification.cancelled event now includes the exact rendered message body for cancelled verifications across supported channels, so webhook consumers can diagnose the event from the payload alone.

The Usage API reference page previously showed an empty data object for most of its twelve endpoints, which left integrators guessing what a CDR row or an AI spend rollup actually looked like. Every response sample now carries the real field names and types the API returns, and a worked sequence at the bottom of the page chains the endpoints the way a finance integration would: read the month's AI spend, create a spend alert rule and preview its breach state, then page the CDR and pull the CSV export with its Content-Disposition filename.

US SMS compliance was documented control by control, with no single page that connected the pieces. The new [US SMS regulatory model](/concepts/us-sms-regulatory-model) concept page gives a compliance officer one read to answer three questions: what Devotel Orbit enforces, what you configure, and where the federal guard sits.

- **The three rule books, ordered** — TCPA sets the legal floor, the CTIA Messaging Principles turn it into the operational checklist carrier audits run, and carrier A2P registration and filtering enforce the result; the page maps each to the Orbit surfaces that answer it.
- **The opt-in and opt-out sums-of-parts** — the consent ledger, double opt-in, the consent gate, and the unknown-consent policies on one side; keyword rules, suppression lists, and the DNC and reassigned-number checks on the other, with each control linked to its owning page.
- **The quiet-hours envelope** — your per-channel settings (off by default), the pre-send policy scanner's lane gate, and the platform's single federal voice dialing-window guard, with the SMS-versus-voice asymmetry stated plainly.
- **Lane resolution** — why an untagged send is treated as marketing on the compliance surface: an exemption from a telemarketing rule has to be asserted, never assumed.
- **The health score as the read-out** — how consent coverage, STOP-reply rate, and carrier rejections close the feedback loop before they become throttling.

No behavior changed; this is documentation coverage for shipped compliance surfaces.

In Audience > Segments, the Tracked Link picker under “Retarget by link clicks” now opens when links are available and lets you select one. If there are no tracked links to show, it explains why and offers a retry instead of appearing unresponsive — and links that already loaded stay selectable even if refreshing the list momentarily fails.