> ## Documentation Index
> Fetch the complete documentation index at: https://docs.orbit.devotel.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Orbit CPaaS glossary: messaging, voice, and flows terms

> Definitions for agentic CCC and Orbit terminology across messaging, voice, WhatsApp, flows, verify, numbers, and observability for developers and ops.

## ملاحظة اللغة

عند عدم توفر ترجمة، يظهر المحتوى الإنجليزي أدناه كخيار بديل. حافظ على رموز الأخطاء ومسارات API والكتل البرمجية كما هي عند تنفيذ الخطوات.

# Glossary

Key terms used throughout the Orbit documentation and the customer-communications industry. Orbit is the Agentic Customer Communications Cloud — one platform spanning 9 aaS pillars (CPaaS, CCaaS, UCaaS, AIaaS, NaaS, CSPaaS, RTC PaaS, CXaaS, CDPaaS).

***

## A

**Abandonment Rate**
The share of queued calls that hang up before reaching an agent — the inbound-queue health metric the queue SLA forecast callback webhooks warn about. Orbit projects the abandonment curve per queue and, when the forecast shows the queue missing its target, fires `queue.sla_breach_forecast` before callers bail — see [SLA-breach forecast callbacks](/voice/sla-breach-forecast-callbacks) and the callback documentation in [Callbacks & scheduling](/voice/callbacks-scheduling).

**ACD (Automatic Call Distribution)**
The routing brain of a contact center — the system that decides which specific available agent receives an inbound call once the **IVR** (below) has captured the caller's intent and routed the call into a queue, picking that agent by queue, skill, and availability rather than simple round-robin. Orbit's ACD surfaces include queues, skills-based routing, and the **Omnichannel capacity reservation** (see O) ledger that keeps a blended voice-plus-digital agent from being double-booked before either dispatcher assigns. See the [ACD queue model](/concepts/acd-queue-model) concept and the [Voice queues guide](/guides/voice-queues).

**A2A (Agent-to-Agent federation)**
The open peer protocol (A2A v1.0.0) Orbit agents use to task agents in other organizations and accept tasks from external peers — the agent-to-agent counterpart of **A2P** (below). A peer discovers your agent through its signed Agent Card and sends work as a signed JSON-RPC envelope to the A2A endpoint, carrying the HMAC `x-a2a-signature` header; with a signing key registered, an unsigned or unverifiable envelope is rejected, and with none registered the endpoint fails open. Per-tenant and GA. See [A2A federation](/agents/a2a-federation).

**A2P (Application-to-Person)**
Messages sent from a software application to a human recipient. Includes notifications, alerts, OTPs, and marketing messages. Contrasts with P2P (person-to-person) messaging between individuals, and with **P2A (Person-to-Application)** (below) — the inbound direction, where the consumer initiates contact. See the [full definition of A2P SMS](https://orbit.devotel.io/glossary/a2p-sms) and of [P2A messaging](https://orbit.devotel.io/glossary/p2a-messaging).

**Area Code Overlay**
A NANP (North American Numbering Plan) practice of assigning a second, geographically overlapping area code to an existing region, forcing callers to dial 10 digits (area code + number) for local calls instead of seven. Overlays occur when a region exhausts its available phone numbers under the original area code and a geographic split isn't practical. This mandatory 10-digit dialing affects local-presence number strategies and DID provisioning — see the [full definition](https://orbit.devotel.io/glossary/area-code-overlay).

**AMD (Answering Machine Detection)**
The far-end classifier on an outbound call that decides whether a human or a voicemail/answering machine picked up, so the **Dialer** (below) either bridges the call to an agent or leaves a message instead of burning agent time on a false pickup. See the [full definition](https://orbit.devotel.io/glossary/answering-machine-detection).

**Aggregator**
A connectivity middleman on a message's path — an intermediary provider that bridges a sender's platform onto one or more destination carriers, settling the commercial and routing relationships a direct carrier connection would otherwise settle one-to-one. A *licensed* aggregator route — the carrier-approved path an **SMS Firewall** (below) treats as legitimate — is the sanctioned counterpart of a **Grey Route** (below), which shoehorns A2P traffic onto person-to-person channels outside the carrier's commercial agreements. Orbit sends exclusively over licensed, carrier-approved routes, so a sender never has to weigh an unlicensed shortcut to cut cost. See [how routing and reputation signals sort legitimate from fraudulent paths](/concepts/network-signals-fraud-reputation).

**Agent**
An AI-powered assistant in Orbit that handles conversations or executes tasks autonomously. Agents use LLMs, custom tools, and guardrails to interact with end users via messaging or voice channels.

**Agentic CCC (Agentic Customer Communications Cloud)**
The brand category Orbit's intro line invokes — the one-platform family (per the [FAQ](/reference/faq)) of nine aaS pillars (**CPaaS**, **CCaaS**, **UCaaS**, **AIaaS**, **NaaS**, **CSPaaS**, **RTC PaaS**, **CXaaS**, **CDPaaS**) built around autonomous AI **Agents** (above) rather than human-only tooling. Each pillar named in that list has its own entry in this glossary; start with **CPaaS** (see C) for the API-first pillar and **CCaaS** (see C) for the contact-center pillar, and read [What is Orbit?](/reference/faq) for the umbrella definition.

**AHT (Average Handle Time)**
The average time an agent spends on a single interaction — talk time plus hold time plus after-call wrap-up work — divided by the number of interactions handled; a core contact-center efficiency metric. Orbit computes and returns it as `aht_seconds` across the queue analytics, agent-leaderboard, and queue-comparison endpoints (e.g. `GET /api/v1/voice/queues/{id}/analytics`). See the [full definition](https://orbit.devotel.io/glossary/average-handle-time).

**Attestation**
The STIR/SHAKEN signal that tells a receiving carrier how much the originating carrier could verify about an outbound call — A (full attestation) means the carrier authenticated the caller and confirmed their right to the calling number, B (partial) confirms the caller only, and C (gateway) applies to calls entering the network from an unverified source. On Orbit, the Numbers page tracks each outbound number's attestation level, tier mix, and answer-rate lift over time. See the [full definition](https://orbit.devotel.io/glossary/attestation).

**API Key**
A token used to authenticate requests to the Orbit API. Prefixed with `dv_live_sk_` (live secret), `dv_test_sk_` (test secret), `dv_live_pk_` (live publishable), or `dv_test_pk_` (test publishable).

**Autoresponder**
A messaging flow that answers an inbound message with a canned reply automatically — a keyword incoming on SMS, WhatsApp, or RCS ("JOIN", "HELP", a coupon word) that the platform matches to a configured response with no human in the loop. In Orbit this overlaps **Flows** (below) and the **Agent** (above): the inbound message fires as a `message.received` webhook, a flow or an agent matches the keyword and sends the reply, while the **Opt-In / Opt-Out** (below) entry covers the mandatory `STOP`/`START` handling every keyword program must carry. Build the loop in [Flows](/flows/overview); for a rule-based bot handing into a conversational model, see **Chatbot** under C.

**Aux / Pause Codes**
The named non-available codes an agent picks when they step away — the platform ships defaults (`lunch`, `bio`, `training`, `break`, `coaching`) and owners or admins extend the catalog per tenant. Picking a code moves the agent to the `paused` presence state, which takes them off the voice eligible list while leaving digital claims untouched; the softphone's four-value toggle writes `away` and the API maps `away → paused` at the storage boundary. Optionally, a per-code duration ceiling fires an overrun alert and can auto-return the agent to `available`. See the [agent presence lifecycle concept](/concepts/agent-presence-lifecycle) and the catalogs in [Hold and pause reason codes](/voice/hold-reason-codes).

**AUX code (Agent Unavailability eXecutable)**
The named not-ready reason an agent picks when they step away from queue work — `lunch`, `break`, `training`, `coffee`, `meeting`, whatever your floor actually uses. The term is the telephony industry name ("auxiliary") for the same idea this glossary also files under **Aux / Pause Codes** (above), and it is deliberately distinct from two look-alike vocabularies: a **Disposition** (see D) tag, which records how a conversation *ended* at wrap-up, and a pause or hold reason, which annotates an in-call interruption — an AUX code is neither; it marks why the agent is *unavailable for new work* between conversations. You manage the catalog in the dashboard at **Voice → AUX Codes**, where each code carries a label, an adherence bucket (`available`, `on_call`, `wrap_up`, `break`, `lunch`, `training`, `unavailable`, or `logged_out`), a paid flag, and a sort position — workforce-management reporting rolls the minutes agents spend in each code into those buckets, and the paid flag tells your payroll export whether the time counts. Picking a code moves the agent off the voice eligible list; a typical mapping reads `READY → AUX:break`, and the agent returns with `AUX:break → READY` (or back to `available`) when they resume. Archiving a code is a soft delete — historical status-change rows keep the slug. Full walkthrough in [Manage AUX codes with the break-reason taxonomy editor](/guides/voice-aux-codes).

***

## B

**Brand Vetting / Vetting Score**
The 0–100 score that **TCR (The Campaign Registry)**'s external vetting partners assign to a US 10DLC brand after registration — a measure of how completely and accurately the brand's legal identity (EIN, website, stock symbol where applicable) could be verified. The score sets the brand's daily throughput tier per number: an unscored brand sits at the Low Volume Standard baseline, a score of 50 or higher unlocks Standard, and 75 or higher unlocks Top Tier. Read the current score, or request a re-vet after fixing a low one, through the vetting endpoints in the [Compliance API](/api-reference/endpoints/compliance); the tier math is in the [10DLC registration guide](/guides/10dlc-registration) and the [SMS channel page](/channels/sms). Vetting is the per-brand, TCR-only input — distinct from the cross-channel **Trust Score** (below) that Orbit rolls up across all registration surfaces.

**BYOC (Bring Your Own Carrier)**
The arrangement where you keep your existing telecom carrier — and the rates, numbers, and routing agreements that come with it — while using Orbit for the application layer: IVR, call queues, messaging flows, and reporting. Orbit connects to your carrier over SIP for voice or SMPP for SMS instead of replacing it entirely. See the [full definition](https://orbit.devotel.io/glossary/byoc) and **SIP (Session Initiation Protocol)** / **SMS Gateway** (below).

**Burst Limit**
A per-second throttle that limits how fast a client may issue requests, measured as requests per second (RPS). It is separate from the per-minute quota: a client can sit comfortably inside its per-minute allowance and still be rejected for sending those requests in one burst. Respecting the limit avoids short-lived spikes that would otherwise starve other requests.

**In Orbit,** a request that exceeds the burst limit returns HTTP 429 with a `details.retry_after` field telling the client when to retry. Generic rate settings live in the dashboard under Settings > API Settings, and error bursts can be tuned per tenant by support. See [Rate limits and retries](/concepts/rate-limit-and-cooldown-taxonomy) and the [rate-limit troubleshooting guide](/troubleshooting/rate-limits).

**BAA (Business Associate Agreement)**
The contract a HIPAA-covered tenant executes with Orbit before any **PHI** (see P) enters the platform. Until it is executed, two protections hold: the HIPAA mode toggle (**Settings → Compliance → HIPAA**, or `PUT /api/v1/settings/hipaa`) refuses to flip on with a 403 while your `baa_status` still reads `pending`, and a campaign whose audience is designated PHI-adjacent refuses to launch with `422 HIPAA_BAA_REQUIRED`. Executing the agreement moves `baa_status` to `executed`, which lifts both gates — read your current state with `GET /api/v1/compliance/baa`. The BAA is a **tenant-owned** control: you decide whether PHI is in scope and you execute the agreement; Orbit enforces the gate. See the enable-time gate in [HIPAA enable blocked until the BAA is executed](/troubleshooting/hipaa-enable-baa-not-executed), the launch-time gate in [HIPAA\_BAA\_REQUIRED](/troubleshooting/phi-audience-baa-required), and the compliance page in [BAA posture](/compliance/baa).

**Branded console (white-label)**
The Devotel Orbit console served on a tenant's own domain — `app.yourcompany.com` — so a reseller's customers sign in to the partner's brand rather than to `orbit.devotel.io`. Every request to a branded host resolves through one unauthenticated, edge-cached lookup (`GET /api/v1/public/resolve-domain?host=…`) that maps the Host to its owning organization and tenant; only domains marked **active** are served, so a claimed-but-unverified or DNS-drifted host returns `404 DOMAIN_NOT_FOUND` instead of the console. The reverse lookup (`GET /api/v1/public/resolve-org-domain?org_id=…`) sends an already-signed-in subaccount user home to their branded origin when the sign-in originates on the primary domain. Claim, verify, and activate a branded domain from **Settings → Domains**; when resolve 404s for a host you believe is live, work the [DOMAIN\_NOT\_FOUND on branded-console resolve](/troubleshooting/resolve-domain-not-found) checklist. See the [custom domains and managed SSL concepts](/concepts/custom-domains-and-ssl) and the [branding console white-label guide](/guides/branding-console-white-label).

**Bounce (hard vs soft)**
The recipient-server verdict that a receiving mail server returns instead of accepting an email — the terminal failure status `bounced` on the Delivery Log row that should always trigger a fix instead of a retry. A **hard bounce** is permanent — the address doesn't exist or the domain blocks your sender — and the address lands in the **Suppression list** (below) until you explicitly re-permit it. A **soft bounce** is transient — mailbox-full, provider throttle, a temporary blocklist match — and the platform retries until the message either delivers or the validity window closes it as `expired`. Classify the bounce first, then either route the address to suppression or wait out the retry loop. See the [email bounces and spam complaints](/troubleshooting/email-bounces-complaints) page and the suppression model in [Opt-Out & Suppression Lists](/compliance/opt-out-suppression).

***

## C

**CLEC (Competitive Local Exchange Carrier)**
A landline carrier that competes with the region's former monopoly incumbent carrier — as opposed to an ILEC (Incumbent Local Exchange Carrier) — and that holds numbers and files ports as the carrier of record in its own right. Every carrier of record registers with NECA and receives an **OCN** (below), the code a port-out request names in its `target_carrier_ocn` field. When you move a number off Orbit, the gaining carrier is often a CLEC rather than the incumbent. See the port-out flow in [port a number out (port-out)](/reference/faq) and the [porting endpoints](/numbers/porting).

**Call Tracking**
Assigning a unique, or dynamically-inserted, phone number to each marketing channel, ad, or campaign so an inbound call can be attributed back to the source that generated it. Tracking numbers are drawn from the same pooled number inventory used for other Caller ID features and forwarded to the business's existing phone system.

**Caller ID Spoofing**
The fraudulent practice of presenting a falsified calling number so an inbound call appears to come from a trusted source — the attack **STIR/SHAKEN** (above) exists to stop by cryptographically binding caller identity to an attestation level. See the [full definition](https://orbit.devotel.io/glossary/caller-id-spoofing).

**Call Park & the Parked-Calls Lobby**
Putting a live call into one of the organization's nine shared slots — numbered **1 through 9**, the same digits a desk phone dials as `*N` — so any operator can claim it, either from the softphone's Parked Calls lobby or by dialing the slot on a registered device. Parking is distinct from holding, which keeps the call device-local and visible only to the holder, and from a warm transfer, which addresses one named destination rather than publishing the call to the floor. The lobby is the aliasing model laid on those slots: any operator maps a number to its occupant, and "the call is in slot 3" is the same claim as "the call is parked in the lobby." A park that omits the slot auto-picks the lowest free number atomically, while a named slot is deliberate placement — "Billing is on 4" — with a collision rejected and answered, never race-resolved. A slot that nobody claims recalls the parking operator after the recall window and auto-releases on the queue's park timeout, and supervisors audit the claim rather than treat lobby reclaim as a coaching takeover. See the [Call park and the lobby: the slot aliasing model](/concepts/voice-call-park-lobby) concept page, the [voice call park troubleshooting](/troubleshooting/voice-call-park) page, and [Voice queues](/guides/voice-queues).

**Campaign**
A coordinated, time-bounded outbound effort aimed at a defined audience — a promotion, an announcement, a reminder, or a re-engagement — with a measurable objective. Campaigns typically target a contact list or segment and track delivery and response as their result metrics.

**In Orbit,** campaigns are created from the dashboard under Campaigns or through the public campaigns API, scheduled to a start time, and reported with deliveries, failures, replies, and opt-outs. See [Campaigns](/campaigns/overview).

**Channel**
A communication medium: SMS, WhatsApp, RCS, Viber, Email, or Voice. Orbit provides a unified API across all channels. Each shipped channel has its own entry in this glossary (see the [Channels hub](/channels) for the full surface).

**Chatbot**
A software program that holds a text or voice conversation with a person — answering questions or completing tasks without a human in every exchange. The term spans two architectures: rule-based bots that match keywords against a scripted decision tree and break outside the scripted path, and LLM-driven **Agents** (see A) that reason over each turn, call **Tools** (below), and hand off to a human in the **Handoff** (see H) cycle when their confidence drops. An Agent is Orbit's chatbot implementation — the bot is an Agent, bound to channels and tools, and the **Containment** (below) metric measures how much traffic it absorbs. See [Agents overview](/agents/overview).

**CNAM / Caller ID Branding (RCD)**
The name a recipient's handset displays for an inbound call, beyond the raw digits. CNAM (Calling Name) is the traditional path: the terminating carrier dips a LIDB (Line Information Database) to look up the name the number's carrier of record registered, so a call lands as "ACME SUPPORT" instead of just a number. RCD (Rich Call Data) is the newer branded-calling path that attaches a verified name and logo through the STIR/SHAKEN authentication chain rather than a carrier database lookup. Both are part of the **Trust Score** rollup (below) — manage per-number registrations, dips, and spam-label remediation in [CNAM & Caller ID](/numbers/cnam), and see the identity surfaces in [Brand Identity & Trust Score](/concepts/brand-identity-trust-score).

**Concatenated / Multi-Part SMS**
An SMS longer than one **Segment** (below), split at send time into multiple segments that the sender chains with a User Data Header (UDH) so the recipient's handset reassembles them into one visible message. The UDH consumes 7 bytes inside every part, which is why the per-segment budget drops when a message overflows — **GSM-7** (above) goes from 160 characters single-part to 153 per part, and **Unicode** (below) from 70 to 67 — so a 161-character text counts as two segments, not one. Orbit computes and reports the segment count per message at the API layer; the encoding mechanics are in [SMS segments & encoding](/concepts/sms-segments-and-encoding) and the billing impact in the [pricing & throughput guide](/guides/voice-messaging-pricing-throughput).

**Cohort**
A fixed membership list carved from a live audience at one moment — distinct from a **Segment** (below), whose membership re-evaluates on a refresh cadence. Because membership is frozen at creation, a cohort stays stable for holdout, attribution, and retargeting reads; capturing a later window means generating a fresh cohort rather than refreshing the old one. Orbit's CDP uses cohorts for click-cohort retargeting (the contacts who clicked a specific link in a prior campaign, attributed at generation) and for incrementality measurement (the treated vs. control cohorts a conversion-lift report compares). See the [audience autosuggest and cohort export concept](/concepts/audience-autosuggest-and-cohort-export) and the [incrementality holdout model](/concepts/cdp-ad-audience-incrementality).

**Contact**
An individual person or recipient whose details are stored for campaigns, conversations, and agent context.

**In Orbit,** a contact is identified by a phone number, an email address, or both, and can carry tags, custom fields, and communication preferences that drive targeting and personalization. Conversations in the Inbox and campaign sends both tie back to contacts. See [Contacts](/contacts/overview) and [Inbox](/inbox/overview).

**Cobrowse (Co-browsing)**
Real-time screen sharing between a customer and your support agent: the customer starts a live session from the web-chat widget, and the agent sees the same page from the inbox as the customer navigates it. Co-browse mirrors the page the customer is on — it is not a video call and never transmits other tabs or applications — and the customer controls the access level (view-only, or guided with explicit consent) and can end the session instantly from their side. Distinct from **UCaaS** softphone/video on the same tenant and from **Conference** (below), which are voice surfaces rather than page-sharing. The endpoints are in the [Cobrowse API](/api-reference/endpoints/cobrowse).

**Conference**
A multi-participant voice bridge: callers dial into — or are placed into — one room identified by a conference ID, and every participant hears every other, unlike a **SIP Trunk** (below) single-leg call that connects exactly two parties. Orbit reports a conference's lifecycle through `conference.created` (the room opens), `conference.participant_joined` / `conference.participant_left` (per-leg arrivals and departures), and `conference.ended` (the room closes, always the last event for that conference ID) — see [Conference Events in the webhook reference](/reference/webhook-events).

**Consent Receipt (Kantara)**
The tamper-evident JSON artifact a **Consent Manager** (India's DPDP Act concept — a registered intermediary) issues for each consent record, modeled on the Kantara Initiative's consent-receipt specification. Each receipt carries a `receipt_id`, the purpose, the fiduciary, the timestamp, and an ECDSA P-256 signature over a sorted-key JSON canonicalization of the payload. Orbit verifies the signature against the public key you registered before anything persists — only verified receipts are stored as consent, and a failed check returns `422 CONSENT_RECEIPT_INVALID` (structurally-degenerate receipts fail earlier as `422 VALIDATION_ERROR`). Register managers, mint receipts, and re-verify them during an audit over [Consent Management & Receipts](/compliance/consent-management); walk the specific failure shapes on the [consent-receipt-invalid troubleshooting page](/troubleshooting/consent-receipt-invalid).

**BYOK (Bring Your Own Key)**
The tenant-owned control plane that records which encryption key — held in **your** external KMS (AWS KMS, Google Cloud KMS, Azure Key Vault, or HashiCorp Vault) — governs your organization's key-management posture: you register a key *reference* (an ARN, resource name, or vault path), and no key material ever leaves your KMS. A registered key walks one lifecycle — `pending → active → revoked`, with **rotate** usable from either live state and `revoked` re-opened only by registering afresh — and every register, activate, rotate, and revoke writes an audit-log entry. Setting the `enforce` flag records the key as your organization's governing policy: platform field-encryption calls that consult BYOK then fail closed with `409 BYOK_KEY_UNAVAILABLE` when the key is revoked, unprovisioned (no wrapped data-encryption key yet), or its wrapped DEK can't be recovered — no silent fallback to the platform key — while a ciphertext that can't be resolved on *read* surfaces instead as `502 DECRYPTION_FAILED` (see the [Error Code Reference](/reference/error-codes)). BYOK never re-encrypts tenant data and Orbit never mandates it: platform-managed encryption stays authoritative for tenant data at rest whatever your BYOK config says. The full model is in [Customer-Managed Keys (BYOK)](/compliance/byok-customer-managed-keys) and the dashboard walkthrough in [BYOK: register, activate, rotate, and revoke](/guides/compliance-byok-keys).

**Customer-Managed Keys (CMK)**
The term your auditor uses for the same control **BYOK** (above) implements: the encryption-key authority sits with you, not the platform, and the dashboard page that drives it is literally named **Settings → Compliance → Customer-Managed Keys**. Keep this tenant-owned distinction straight — platform-managed keys encrypt tenant data at rest with no action from you, while customer-managed keys record *your* governing key as compliance evidence and gate the BYOK seam; one never substitutes for the other, and rotation, revocation, and the audit trail are yours to run and prove. The reference page carrying the full model is [Customer-Managed Keys (BYOK)](/compliance/byok-customer-managed-keys).

**CSAT (Customer Satisfaction Score)**
The post-interaction satisfaction rating a customer returns through a survey — collected per conversation and delivered to your application as `survey.response` webhook events. See the [survey endpoints](/api-reference/endpoints/surveys) and the survey events in the [webhook reference](/reference/webhook-events).

**Conversational AI**
Technology that understands natural-language input and holds a human-like, multi-turn exchange over text or voice, combining NLP, machine learning, and dialog management rather than matching input against a fixed script or menu. An **Agent** (above) is the specific LLM-based implementation of conversational AI that Orbit ships — see the [full definition](https://orbit.devotel.io/glossary/conversational-ai).

**Customer Journey**
The full sequence of interactions a customer has with a business across every channel — SMS, voice, email, WhatsApp, video, and the contact center — from first contact through onboarding, day-to-day usage, and renewal or support. A journey only becomes visible when identity resolution stitches those touchpoints back to one profile, and orchestration turns the mapped stages into automated next steps with advance rules and channel fallbacks. On Orbit, journeys run on the unified interaction history of the contact profile — see the [full definition](https://orbit.devotel.io/glossary/customer-journey).

**Compliance Profile**
The named, reusable packet of verified identity and business data — legal entity, address, contact, and supporting documents — that a phone-number purchase, a **Sender ID** (below) registration, or a brand verification draws from instead of re-asking for the same paperwork. Profiles follow a review lifecycle (`draft → pending_review → approved`), and a number waiting on one idles at `pending_compliance` until the profile it needs is attached and approved — see [Troubleshoot a pending number or Sender ID](/compliance/troubleshooting-pending-gated-surfaces) and the assembly guide in [Assemble your tenant's compliance posture](/guides/compliance-profiles-assemble).

**Containment**
The share of an **Agent**'s (above) conversations that close without a human **Handoff** (below) — the metric that answers "how much live traffic is the bot actually absorbing?", distinct from the pre-ship evals score, which tests the agent against a fixed prompt set. See the [AI Containment and Resolution dashboard](/guides/agent-containment-dashboard).

**Conversational Commerce**
Completing a purchase — browsing a catalog, adding to cart, paying, and receiving order updates — inside the same messaging thread a customer already uses to chat with a business, rather than redirecting them to a separate website or app. Marketer Chris Messina coined the term in 2015. Orbit ships conversational commerce across WhatsApp and RCS product catalogs, a channel-agnostic pay-by-link checkout, and a unified cross-channel cart — see **Channel** above and **RCS (Rich Communication Services)** below.

**Conversational Experience**
The overall quality of a customer's back-and-forth interactions with a business across digital channels — SMS, WhatsApp, RCS, web chat, email, and voice — as a continuous, contextual dialogue rather than one-way broadcasts or a form the customer fills out and waits on. It doesn't require AI: a shared inbox with human agents replying quickly and seeing a customer's full cross-channel history already delivers one. **Conversational AI** (above) is one way to scale that same quality of interaction to more channels and volume — see the [full definition](https://orbit.devotel.io/glossary/conversational-experience).

**Conversational Marketing**
A demand-generation approach that replaces static lead-capture forms and drip email funnels with real-time, two-way dialogue — live chat, a chatbot, or a messaging channel like SMS, WhatsApp, or RCS — to engage a website visitor or prospect the moment they show interest and route them to a demo, a purchase, or a human seller instantly instead of making them wait on a follow-up email. It sits earlier in the funnel than **Conversational Commerce** (above), which focuses on completing the purchase itself, and the two often run on the same channels — see the [full definition](https://orbit.devotel.io/glossary/conversational-marketing).

**Conversational Support**
Customer service delivered through a natural-language chat interface — usually an AI-powered chatbot — that lets a customer ask a question in their own words and get an answer immediately, instead of navigating a phone menu, filling out a form, or waiting on hold for a live agent. **Agent** (above) is the Orbit building block that answers routine account, order, and billing questions this way and hands off to a human contact-center agent with the full conversation history when needed — see the [full definition](https://orbit.devotel.io/glossary/conversational-support).

**CASL (Canada's Anti-Spam Legislation)**
Canada's federal anti-spam statute (S.C. 2010, c. 23, enforced by the CRTC) governing **commercial electronic messages** — email, SMS, and similar — sent to Canadian recipients. Unlike the US opt-out model of **CAN-SPAM** (below), CASL is largely an **opt-in** regime: you need consent before you send, either **express** (the recipient affirmatively asked to receive your messages — documented and durable until withdrawn) or **implied** (an existing business relationship or a conspicuously published address, both time-limited), plus sender identification and a working unsubscribe mechanism in every message. Meeting CASL is a **tenant-owned** control: Orbit gives you the send surfaces, the consent ledger, and the suppression layer that makes an opt-out stick — map each obligation to the surface you already have in the [CASL guide](/compliance/casl-canada-anti-spam).

**Conversational UI (CUI)**
An interaction design pattern where a person completes a task by typing or speaking in natural language — through chat or voice — instead of navigating fixed menus, forms, or button taps. **Conversational AI** (above) is the underlying technology that powers a conversational UI; the UI is the chat window or phone call the person interacts with — see the [full definition](https://orbit.devotel.io/glossary/conversational-ui).

**CPaaS (Communications Platform as a Service)**
A cloud-based platform that enables developers to add real-time communication features (messaging, voice, video) to applications via APIs, without building or operating carrier infrastructure themselves. Contrasts with **UCaaS**, which packages finished internal-communication tools (softphone, SIP trunking, team calling) for a business's own staff rather than API building blocks a developer integrates into their own product — see **UCaaS** below and the [full definition](https://orbit.devotel.io/glossary/cpaas), which also distinguishes CPaaS from CCaaS.

**CCaaS (Contact Center as a Service)**
Cloud contact-center software that runs a business's customer-facing support and sales floor — ACD queues, IVR, adherence, and the agent seat — as a rented service instead of a premises PBX, aimed at contact-center operators rather than developers. Contrasts with **CPaaS** (above), which supplies the API building blocks, and **UCaaS** (U section), which is internal staff communication rather than customer-facing queue work; the same tenant carries all three. Orbit ships CCaaS through queues, wrap-up codes, presence, and coaching — see [UCaaS, CCaaS, and CPaaS](/concepts/ucaas-ccaas-cpaas) for the pillar split and the [ACD queue model](/concepts/acd-queue-model) for how queue dispatch works.

**AIaaS (AI Agents as a Service)**
The pillar that runs autonomous AI agents as a managed service — you author an agent and hand it channels and tools, and the platform hosts the model connectivity, knowledge retrieval, guardrails, and handoff machinery, rather than you operating the runtime. AIaaS is one of the nine **Agentic CCC** (see A) pillars; an individual **Agent** (see A) is the unit you build on it. Orbit grounds AIaaS in the [AI agent architecture concept](/concepts/ai-agent-architecture), the [Agents overview](/agents/overview), and the **MCP** protocol (M section) agents use to call external tools.

**CSPaaS (Communications Service Provider as a Service)**
The white-label and reseller pillar — the toolkit that lets an operator run a full communications platform under their own brand and resell it, rather than Orbit being the provider their customers see. It serves resellers, agencies, and operators who issue each customer an isolated **Subaccount** (see S): provision, suspend, or close sub-accounts from one parent, rebrand the dashboard on your own domain, set reseller margins, fund prepaid credit from the parent balance, and cap each customer with `monthly_spend_cap_cents`. Orbit ships CSPaaS through the [subaccount organization model](/concepts/subaccount-organization-model) and the [Branding console and white-label guide](/guides/branding-console-white-label) on the [white-label feature page](https://orbit.devotel.io/white-label).

**CXaaS (Customer Experience as a Service)**
The experience-analytics pillar — the measurement layer that scores every interaction so an operator answers "how did it go?" and "how is my team doing?" across every conversation, voice or digital. Orbit computes sentiment, topics, quality, and resolution over agent and human conversations, then rolls aggregates, leaderboards, and surge signals into dashboards and APIs. Pair with **CDPaaS** (above): CDPaaS stores the customer's profile and events; CXaaS scores the experiences against them. See [Conversation Intelligence](/concepts/conversation-intelligence) and the [Analytics pipeline concept](/concepts/analytics-pipeline).

**Cascade (Message Cascade / Fallback Chain)**
The ordered fallback chain a message escalates through when the current hop can't deliver — an undeliverable RCS send falls back to SMS, and every hop carries one shared `message_group_id` so the whole run reads back as one logical message rather than a set of disconnected sends. Escalate per send with a cascade field or arm an org-level default policy, then read a finished chain as a single group: see [Cascade failover policy and logical cascade groups](/concepts/message-cascade-groups) and the dashboard-side [Track a cascade guide](/guides/track-a-cascade). Related to **Fallback Channel** (below), the per-channel retry concept this policy mechanism generalizes.

**CDPaaS (Customer Data Platform as a Service)**
The customer-data pillar — one hosted platform that collects behavioral facts about your customers, resolves them to a single identity, and computes traits, segments, and attribution from the same event stream, so support, marketing, and AI agents all read one profile. Everything arrives as an append-only CDP event (per the [CDP event model concept](/concepts/cdp-event-model)) on Segment-compatible ingest endpoints, and identity resolution folds repeated identifiers into one contact. Pair with **CXaaS** (below), the analytics pillar that reads these profiles. See the [CDP event model](/concepts/cdp-event-model), the [identity-resolution and merge semantics concept](/concepts/cdp-identity-resolution), and the [CDP API](/api-reference/endpoints/cdp).

**CDR (Call Detail Record)**
The per-call billing and observability record — legs, durations, and per-call charges — that billing exports are reconciled against. Orbit walks the export-to-reconciliation flow in [CDR exports & billing reconciliation](/billing/cdr-export-billing-reconciliation). See the [full definition](https://orbit.devotel.io/glossary/call-detail-record).

**CAN-SPAM (Controlling the Assault of Non-Solicited Pornography And Marketing Act)**
The US commercial-email statute (15 U.S.C. § 7701 et seq., enforced by the FTC) — the American counterpart to Canada's opt-in **CASL** (above), working on an **opt-out** model: you may email before consent, but after the first unsubscribe you may not email again. The FTC summarizes it in seven content requirements: no false or misleading header information, no deceptive subject lines, identification of the message as an advertisement where required, a valid physical postal address, a clear explanation of how to opt out, an honored opt-out mechanism (processed within 10 business days), and monitoring of anyone you hire to send on your behalf. Complying is a **tenant-owned** burden — Orbit supplies the send surfaces (sender domains, templates, headers) and the suppression layer that makes an unsubscribe actually stick. The detailed mapping is in the [CAN-SPAM guide](/compliance/can-spam).

**Cursor-Based Pagination**
A pagination method where each response includes an opaque cursor token pointing to the next page of results. More stable and performant than offset-based pagination.

**Message Route Trace**
The per-message ordered timeline `GET /api/v1/messages/:id/trace` returns — one event list over the message row and its webhook delivery log, covering `accepted` → `validation` → `queued` → `routed` → `sent` → the terminal receipt (`delivered` / `failed` / `undelivered` / `rejected` / `read` / `expired` / `submitted_no_receipt`), plus one `webhook_fanout` event per delivery to your webhook endpoints. Because it is assembled from persisted rows, a trace reflects history — it never re-queries the carrier live, and it is the diagnostic surface for the "delivered-but-never-received" symptom, naming the provider and MCC/MNC carrier hop you would hand to a carrier-side trace request. See [the route-trace concept page](/concepts/message-route-trace).

***

## D

**Agent Distress Alert (panic button)**
An operator-facing panic control on the active-call screen of the softphone. An agent presses it to flag a hostile caller, a threat, or another safety concern; there is no confirmation dialog and no required reason. In Orbit, the authenticated session calls `POST /api/v1/voice/agents/me/distress`, and the `/me/` scope takes the agent identity from that session so one agent cannot spoof another. The press forces recording **on** for that call regardless of queue policy (it never turns recording off), publishes `agent.distress.raised` to the omnichannel supervisor stream within roughly 50–100 ms, appends a per-tenant audit row with the severity, reason, and recording outcome, and persists a durable incident row even if a supervisor dismisses the alert. Both rows follow the tenant's standard retention windows. Pressing the control does not consume credits. This is different from [Supervisor Coaching Modes (listen / whisper / barge / takeover)](/reference/glossary#supervisor-coaching-modes-listen--whisper--barge--takeover), which let a supervisor listen silently, whisper, barge, or take over an active call after an alert. See the [Agent distress alert model](/concepts/agent-distress-alert-model) and [Retention windows and deletion](/concepts/retention-windows-and-deletion) for the incident lifecycle and tenant retention rules.

**Panic Button**
Another name for the **Agent Distress Alert (panic button)** above — the softphone control for raising a durable safety incident during a live call.

**DNS verification (sending domain)**
The periodic re-validation of the SPF, DKIM, and DMARC records behind a sending domain that confirms the domain may send through the provider — an ongoing health check, not a one-time approval. Orbit's email dashboard shows a traffic-light chip per record type: green resolves to the expected value, yellow is partial or inconclusive, and red is a confirmed failure. When a record drifts, sends from the domain fail at the provider with a 403 "domain is not verified" rejection. See the recovery loop on the [email DNS-drift troubleshooting](/troubleshooting/email-dns-drift) page.

**DNC / DND Registry (Do-Not-Call / Do-Not-Disturb)**
A per-country list — run by a regulator or telecom authority — of phone numbers whose owners have opted out of unsolicited telemarketing calls or messages. Each country sets its own scope, category rules, and scrubbing cadence, so a sender contacting numbers in several countries checks each country's registry. In Orbit, scrubbing against those registries is a tenant-owned control you configure per sending region, alongside the STOP-based **Opt-In / Opt-Out** (below). See the [full definition](https://orbit.devotel.io/glossary/dnc-registry).

**DNO (Do-Not-Originate)**
A curated list of calling-party numbers that must never be presented as the outbound caller ID — numbers that are invalid, unallocated, inbound-only, or spoof-bait such as impostor IRS, bank, or government lines. Where **DNC/DND** (above) gates the *recipient*, DNO gates the *source identity*: Orbit checks the resolved `from` at origination time and hard-rejects a match with `422 VOICE_DNO_BLOCKED` before dispatch, so no wallet deduction happens. The list is a **tenant-owned** control — it ships empty by default, because no universal safe set exists, and you opt in by curating it. The effective set reconciles two layers: a platform env baseline (`DEVOTEL_VOICE_DNO_NUMBERS`, a CSV) and a per-organization `dno_override` selecting one of three modes — **extend** (default: add entries to the baseline), **replace** (your list supersedes the baseline), or **subtract** (waive one baseline entry) — and matching is prefix-based, so one entry can block a whole unallocated range. See the full configuration model in [Do-Not-Originate (DNO) caller-ID blocking](/compliance/do-not-originate), the send-time gate triage in [voice destination blocks](/troubleshooting/voice-destination-blocks), and the error code in the [Error Code Reference](/reference/error-codes).

**DPDP (India — Digital Personal Data Protection Act)**
India's national data-protection statute (the Digital Personal Data Protection Act, 2023) — the Indian member of the jurisdiction set a **DSAR** (below) can carry, granting data principals rights over their personal data and obligating data fiduciaries to base processing on consent or another lawful use. Its distinctive mechanism is the **Consent Manager**: a registered intermediary through which a data principal gives, manages, and revokes consent, issuing a tamper-evident, Kantara-style signed **Consent Receipt** (below) per consent record. Orbit models that intermediary directly in your tenant-owned consent registry — you register the manager and its public key, and the platform verifies each receipt's ECDSA signature before anything persists; a failed check returns `422 CONSENT_RECEIPT_INVALID`. Register managers and mint receipts over [Consent Management & Receipts](/compliance/consent-management); trace the failure shapes on the [consent-receipt-invalid troubleshooting page](/troubleshooting/consent-receipt-invalid).

**DLT (Distributed Ledger Technology)**
India's telemarketing-compliance framework, mandated by **TRAI** (the Telecom Regulatory Authority of India — below): every business sending A2P SMS to Indian recipients must register itself as a Principal Entity, its Sender IDs (Headers), and its message content templates on a per-carrier DLT ledger before any traffic delivers, and the operators themselves — not Orbit — reject unregistered or mismatched sends. This is the telecom-industry meaning of "ledger" — each carrier records registrations on its own distributed ledger — not the generic blockchain meaning the acronym also carries. Orbit mirrors your DLT artifacts as a tenant-owned registry so the Indian registrations sit alongside the rest of your compliance posture: record your Principal Entity ID, Headers, and templates and track their status in the [DLT-India registry](/compliance/dlt-india). You still complete the underlying registration on a registrar's DLT portal; Orbit records the resulting IDs. See also **Sender ID (Alphanumeric)** (below) and **10DLC** (below) — the local counterparts of the same registration idea.

**TRAI (Telecom Regulatory Authority of India)**
The Telecom Regulatory Authority of India, India's telecom regulator. Among other duties it administers the country's spam-control framework for commercial messaging, including the Distributed Ledger Technology (DLT) scrubbing registry that SMS templates, sender identities, and consent records must be registered with before they take traffic.

**In Orbit,** tenants sending SMS into India register their templates and sender IDs on DLT, and message formatting for Indian destinations is surfaced in the India compliance guides rather than being a platform-global gate. See [Compliance](/compliance/overview) for tenant-owned compliance controls.

**DSAR (Data Subject Access Request)**
The formal mechanism a person uses to exercise their privacy rights over the personal data you hold about them — access, deletion, correction, portability, or opting out of the sale of the data — under **GDPR** (below), CCPA/CPRA, LGPD, PDPA, PIPEDA, and DPDP (India). Most privacy laws set a hard response deadline (30 days under GDPR, 45 under CCPA/CPRA), and Orbit's SLA tracker applies the statutory clock based on the jurisdiction the request carries. Access and portability requests trigger the export flow — an operator-filed endpoint or a public self-service portal that verifies identity with a two-factor email + SMS OTP — and once a request has completed, failed, expired, or been cancelled, withdrawing it returns `409 DSAR_NOT_CANCELLABLE`. Erasure requests run as a separate lifecycle: a GDPR Article-17 erasure opens a cancellable cooling-off window (per-tenant, default 7 days), a second pending or executing request against the same contact returns `409 ERASURE_COOLING_OFF_ACTIVE`, and past that window the scheduled hard-delete executes. Fulfilling a request is a **tenant-owned** control — Orbit exports the data and manages the lifecycle; you decide what to disclose and who may act. See the [DSAR guide](/compliance/dsar), the erasure endpoint details in the [Contacts API](/api-reference/endpoints/contacts), and the cancel-or-wait recovery on the [pending-compliance and erasure gates troubleshooting page](/troubleshooting/pending-compliance-and-erasure-gates).

**GDPR (General Data Protection Regulation)**
The EU/EEA data-privacy regulation (with its UK twin) that's the strictest member of the jurisdiction set a **DSAR** (above) can carry. It splits rights into Article-15 **access** requests (disclose the data held — maps to the `know` request type and `access` public portal verb), Article-16 **rectification**, Article-17 **erasure** ("right to be forgotten," the cooling-off lifecycle above), and Article-20 **portability**. Orbit's response-SLA tracker gives GDPR requests a 30-day clock. Configure your posture in the [GDPR posture guide](/compliance/gdpr-posture-guide); when an Article-17 filing or a send to the subject's contact is refused with `409 ERASURE_COOLING_OFF_ACTIVE` or `422 CONTACT_ERASURE_PENDING`, the [pending-compliance and erasure gates troubleshooting page](/troubleshooting/pending-compliance-and-erasure-gates) covers the cancel-or-wait recovery. Confirm jurisdiction handling with counsel — the [DSAR guide](/compliance/dsar) is not legal advice.

**Deliverability Score**
A single number, usually 0-100, estimating how likely an email is to reach its recipient before it is sent — combining a per-message content lint (spam-trigger keywords, shortened links) with the sending domain's and IP's historical **Sender Reputation** (below) inputs: bounce rate, spam-complaint rate, and engagement patterns. Unlike a delivery rate (a historical metric), it's predictive: catching likely filters before a send so you can adjust and reduce bounce/spam-penalty exposure. See the [full definition](https://orbit.devotel.io/glossary/deliverability-score).

**Delivery Rate**
The historical, fleet-wide share of your outbound messages that confirmed delivered — delivered receipts divided by submitted sends — measured across a channel or your whole tenant after the fact. Unlike the predictive **Deliverability Score** (above), which estimates likelihood *before* a send, the delivery rate recounts what actually landed: you read it to watch for a route, sender, or destination degrading over time rather than to lint the next message. Query the aggregate per channel over `GET /api/v1/analytics/deliverability` (see [Analytics](/channels/analytics)); decode the per-row statuses behind it on the [status-by-row reference](/reference/troubleshooting).

**DID (Direct Inward Dial)**
An individual phone number on your account — the address a customer dials directly (no extension, no switchboard) and the identity a message or call shows as its source. On Orbit every operation hangs off DIDs: porting moves them, **Number Porting** (below) being the canonical example; a **Sender Pool** (below) draws its routing rotation from them; a call or reply pins to the DID it arrived on (`sender_dids` in the API, `number` on inbound webhooks). The capability profile per DID — voice, SMS, MMS, toll-free — is per country: [country capabilities](/numbers/country-capabilities). See [Numbers overview](/numbers/overview) and how routing resolves a DID in [Sender & Routing](/concepts/sender-and-routing); the per-number endpoints are in the [Numbers API](/api-reference/endpoints/numbers).

**DNIS (Dialed Number Identification Service)**
The called-number value a PBX or SBC presents when it hands a call to the platform — the number *a caller* dialed, so one organization receiving thousands of inbound lines can route differently per DNIS value even when the calls all arrive on the same SIP trunk. On Orbit the DNIS is the input to every inbound voice decision: the resolver reads it at call setup, finds its owning organization, and applies the **per-number route** first, then your **DNIS pattern rules** (an E.164 prefix like `+1800`, or a full regex over the dialed digits, evaluated by priority, then longest pattern, then oldest rule), then the org default — so a toll-free pool steers to one queue while a VIP line carved out per-number still beats the pattern. **Pattern rules never touch outbound termination** — DNIS is inbound routing only. Manage the pattern rules on the **Voice → DNIS pattern routing** dashboard page or the `/api/v1/voice/dnis-routes` endpoints; per-DID overrides and DNIS rules together are covered in [Inbound Voice Routing](/concepts/inbound-voice-routing), and the move itself — a whole DID, rules included — crosses carriers through **Number Porting** (see N). See also the dashboard walkthrough in [Route many inbound numbers to one queue with DNIS patterns](/guides/dnis-pattern-routing).

**DTMF (Dual-Tone Multi-Frequency)**
The touch-tone signalling system that encodes each telephone keypad press as a pair of audible frequencies, so an automated system can tell digits, `*` and `#` apart. Interactive voice menus (IVRs) collect DTMF as their input, for example "press 1 for sales." Keying a digit during an automated call is sometimes called "touch-tone entry."

**In Orbit,** IVR prompts in the visual builder accept a caller's digit presses, and the gathered digits become flow variables you can branch on. See the [IVR visual builder guide](/guides/ivr-visual-builder) and the **IVR** entry above.

**Dialer**
The automated outbound-calling engine that works through a **Campaign** (above) contact list and originates voice calls on your behalf — a campaign is the audience and message definition, and the dialer is what actually places the calls. Orbit's dialer runs in three modes: **preview** (an agent reviews each contact card, claimed atomically via `GET /api/v1/dialer/next-call`, then launches the call), **power/progressive** (the pacing engine originates calls as agents free up), and **predictive** — the mode industry calls a **predictive dialer** — where the pacing engine dials ahead of agent availability, using answer-rate predictions to keep agents talking while holding nuisance calls down, and connects answered calls to the next free agent. Answering-machine detection (AMD) determines whether a human or a voicemail picked up, tying into **Call Tracking**'s (above) spam-alert remediation so outbound numbers keep a clean answer-rate profile. For US recipients the dialer enforces the federal TCPA dialing window as a hard block with no override — see the [TCPA dialing-window troubleshooting](/troubleshooting/tcpa-window-blocked-calls) and the [Dialer API](/api-reference/endpoints/dialer).

**Disposition (Call Disposition)**
The outcome tag an agent submits when a conversation ends. Orbit carries two axes: **wrap-up codes** — a per-queue catalog with exactly one required or optional code per conversation, which can gate the `busy → available` return from **Wrap-up / ACW** (below); and **disposition tags** — a tenant-wide catalog of labels (many stamps per call: *lead*, *vip*, *escalated*) used for cross-cutting analytics and segment filtering rather than outcome enforcement. See [Wrap-up codes](/voice/wrap-up-codes), [Call disposition tags](/voice/call-disposition-tags), and the outbound-dialer variant in [Dialer dispositions](/voice/dialer-dispositions).

**DLQ (Dead-Letter Queue)**
The catch-all lane a failed **Webhook** (below) delivery lands in after every retry tier exhausts — a delivery that burnt through all \~10 attempts across roughly 4.3 hours of exponential backoff, or one sent to an endpoint Orbit already auto-disabled after 50 consecutive failures or a proven-dead `401`/`403`/`404`/`410` response. Dead-lettered deliveries stay replayable for 7 days: list them with `GET /api/v1/webhooks/dlq` and put one back into the retry pipeline with `POST /api/v1/webhooks/dlq/{delivery_id}/replay` (all under the [Webhooks API](/api-reference/endpoints/webhooks)); the same inbox sits in the dashboard under **Developer → Webhooks → Dead-letter queue**. A DLQ event is still recoverable — distinct from a suppressed recipient (the **Suppression list**, below) and from a corrupted artifact quarantined on a failed integrity check (recordings, archives) — so triage the lane before replaying. For recurring failures — signature mismatches, disabled endpoints, flapping receivers — see [signature verification troubleshooting](/webhooks/troubleshooting-signature-failures) and the [webhook deliveries, retries, DLQ, and replay](/troubleshooting/webhook-deliveries) troubleshooting page.

**DLR (Delivery Receipt)**
The status callback a carrier or messaging gateway returns after an SMS, MMS, or WhatsApp message is submitted, confirming whether it was delivered, failed, or is still pending — and why, via a carrier status code. DLRs arrive asynchronously, seconds to minutes after the send, since they depend on the destination carrier's own delivery confirmation. On Orbit, a message sits in `submitted_no_receipt` (an intermediate state) until a DLR lands, and receipts arriving past the configured late-arrival window close the message as `expired`. Both transitions surface via `message.failed` — see [Message Events in the webhook reference](/reference/webhook-events). The full status vocabulary a DLR drives is the **Message Status Lifecycle** (see M) entry. See the [full definition](https://orbit.devotel.io/glossary/dlr).

**Delivery Log**
The dashboard + API surface you use to inspect per-message rows — one searchable, filterable list across SMS, WhatsApp, email, and voice, reached in the dashboard from **Messages → Tools → Delivery log** and queried over, by message ID, provider reference, recipient, sender, status, or direction. It answers "where is my queued/failed/undelivered row, and on which channel?" by working the row to its message detail page and status-timeline. Distinct from the **Message Route Trace** (above), which returns the route-level event list for one message: `accepted` → `validation` → `queued` → `routed` → `sent` → the terminal receipt (`delivered` / `failed` / `undelivered` / `rejected` / `read` / `expired` / `submitted_no_receipt`), via `GET /api/v1/messages/:id/trace` — the log is the fleet-wide search; the trace is the per-message drill-in. See the [Delivery Log guide](/guides/delivery-log) and the row-by-status decoder in the [troubleshooting reference](/reference/troubleshooting); the per-message route step itself is defined in [Message Route Trace](/concepts/message-route-trace).

***

## E

**E.164**
The ITU-T standard for international telephone numbers. An E.164 number starts with a `+`, then one-to-three digits of country code, then the subscriber number — at most 15 digits total, with no spaces, parentheses, or punctuation (for example, `+14155552671`).

**In Orbit,** every phone number you send a message or place a call to is normalized into E.164 format at input, and API sends reject numbers that fail the format, so `+14155552671` and `14155552671` are treated as the wrong-format cases the validation runbook covers. The number lookup API and the validation-gates runbook explain how normalization is applied: see [Phone number lookup](/numbers/lookup) and [Validation gates](/troubleshooting/validation-gates).

**DKIM (DomainKeys Identified Mail)**
A public-key-cryptography signature a sending domain stamps on outbound email so receiving mail servers can verify with the domain's published DNS public key that the message hasn't been altered in transit and genuinely came from that domain. Domain reputation is DKIM/SPF-bound (see **Domain Warmup**, under I), so a domain-level signature survives the sending IP rotating. Orbit's daily DNS health check re-validates the record and flags drift before a receiver rejects on it. See the [email DNS-drift troubleshooting](/troubleshooting/email-dns-drift) page and the [email channel guide](/channels/email).

**E911 (Enhanced 911)**
The emergency-calling service that routes a 911 dial to the correct **PSAP (Public Safety Answering Point)** for the caller's physical location, carrying registered dispatchable-address information with the call. On Orbit, every outbound voice call to an emergency short code (911 in the US/Canada, 112/999/000 elsewhere) is rejected pre-flight with `422 EMERGENCY_CALLING_NOT_SUPPORTED` — a platform **hard guard** with no tenant toggle, so no carrier dispatch happens and no per-minute cost is billed. E911 itself is on the platform roadmap but not yet shipped; until it is, dial emergency services from a regular mobile or landline phone. See the full behavior and the operator obligations it places on softphone surfaces in [Emergency calling](/voice/emergency-calling) and the FAQ entry in the [Voice FAQ](/reference/faq).

**eSIM (embedded SIM)**
The soldered-in / remotely provisioned SIM shape Orbit's **NaaS Connectivity** connector manages — a data-only line identified by its **ICCID** (see I) that carries internet traffic and never terminates a voice call or an SMS. A connectivity SIM walks a four-state lifecycle: `ordered` (created and billed against its plan, no data yet) → `active` (sessions meter against its quota) ⇄ `suspended` (a reversible pause) → `terminated` (the one irreversible door). For consumer-style eSIM plans the `ordered` state also holds the SIM while you issue the end user a self-install SGP.22 activation (an LPA string or QR code). Distinct from the **reseller lane**, where you buy travel-eSIM profiles in bulk to hand to your own end customers under your own pricing — that path runs on **Numbers → eSIM**. See the [Connectivity SIM model](/concepts/connectivity-sim-model), the [Provision and operate eSIM / IoT SIMs](/guides/connectivity-sim-lifecycle) lifecycle guide, and the reseller sibling in [eSIM reseller billing model](/concepts/esim-reseller-billing-model).

***

## F

**Frequency Cap**
The tenant-owned send-admission rule that bound-checks each recipient's rolling send count — "no more than `max_count` sends to this recipient within `window_seconds`" — enforced atomically inside the send pipeline itself, so the limit holds no matter which campaign, flow, or API call attempts the send. Each cap keeps its own counter (a per-cap sorted set keyed by cap id and recipient), the claim is a single atomic check-and-increment so racing send pods cannot both slip through, and a violation is denied synchronously — HTTP 429 `FREQUENCY_CAP_EXCEEDED` with `retry_after_seconds` for a direct API send, or a `skipped` / `frequency_capped` record for a campaign send. Optional category scoping confines a cap to its own traffic class (a marketing-only cap never counts OTPs). Configure and inspect caps in the [Frequency caps guide](/guides/frequency-caps); the counter and gate-order model is in the [frequency-cap model concept](/concepts/frequency-caps-model), and the gate composes with **Quiet Hours** (see Q) and **Opt-Out / Suppression** (see O) in the send-admission chain. See also the CDP terms entry below.

**FCC AI Voice Written Consent**
The US prior-express-written-consent gate for outbound calls placed by an **Agent** (above) with AI-generated voice: a signature recorded as a consent event is required for the destination before the call may originate, and a verbal opt-in does not satisfy it. With no qualifying written consent on file the leg refuses pre-flight with the 4xx `FCC_AI_VOICE_WRITTEN_CONSENT_REQUIRED`, so no carrier dispatch happens; recording consent is a **tenant-owned** control. See the [FCC AI voice consent guard](/compliance/fcc-ai-voice-consent-guard) and the FAQ entry in the [Voice FAQ](/reference/faq).

**Flow**
A reusable automation sequence: a trigger, a series of steps (send a message, call an agent, wait for a reply), and conditions that branch the path. Flows run against contacts who match the trigger and stop when the sequence completes or the contact exits.

**In Orbit,** flows are built in the dashboard under Flows, can combine messaging, voice, and agent steps, and expose per-step analytics so you can see where contacts drop off. See [Flows](/flows/overview).

**FQDN (Fully Qualified Domain Name)**
A complete, unambiguous domain name — `hooks.example.com`, not `hooks` or an IP — that resolves to a public DNS record. **Orbit behavior:** when you register a **Webhook** (below) endpoint URL or a **SIP Trunk** (below) hostname, Orbit validates the host is a public FQDN and rejects loopback (`127.0.0.1`, `localhost`), RFC-1918 private ranges (`10.0.0.0/8`, `172.16.0.0/12`, `192.168.0.0/16`), and reserved name TLDs like `.internal` as `422 INVALID_WEBHOOK_URL`, because an event it can never reach would silently fail delivery. Registering an endpoint whose URL once passed that check but later fails to resolve leaves the delivery in the retry/DLQ path. See [webhook endpoint creation troubleshooting](/troubleshooting/webhook-endpoint-creation) and [SIP-trunk connection troubleshooting](/troubleshooting/sip-trunk).

**Fallback Channel**
A backup channel used when the primary channel fails to deliver. For example, falling back from WhatsApp to SMS if the WhatsApp message is undelivered after 5 minutes.

**Fax (T.38 / IP Fax)**
The Fax channel sends and receives faxes over T.38 / G.711 via one upstream carrier — a named carve-out from Orbit's outbound-termination policy (voice and SMS exit only through the Devotel softswitch; fax/T.38 and MMS are the two exceptions). Documents travel as PDF or TIFF, and billing is **on-success-charge**: a failed attempt (busy, no-answer, line-quality) is not billed, only a confirmed successful transmission deducts the wallet. See the [Fax channel page](/channels/fax) and the [Fax send workflow guide](/guides/fax-send-workflow).

**Fine-tuning**
Continuing to train a pre-trained language model on a smaller, curated dataset specific to a task, domain, or writing style, so the model's own weights adjust to that narrower use case instead of relying only on the general model plus a prompt. Unlike **RAG** (below), which retrieves source content at query time, fine-tuning bakes the adjustment permanently into the model's weights — see the [full definition](https://orbit.devotel.io/glossary/ai-fine-tuning).

**Flashcall**
A missed-call OTP channel on the **Verify** service: instead of texting or speaking a code, `POST /verify/send` with `channel: "flashcall"` places a short outbound call — dropped before pickup — from a rotating caller-ID pool, and the trailing digits of that caller ID are the code the recipient enters. The recipient never answers anything, which removes a step the recipient's device can auto-capture. Until a caller-ID pool is provisioned for the channel, the send fails closed with `503 SERVICE_UNAVAILABLE`. Distinct from **SNA (Silent Network Authentication)** (below), which confirms device possession with no code at all. See [Verify](/verify/overview) for the delivery-channel split and the CLI-pool requirement.

**FOC (Firm Order Commitment)**
The carrier-committed date the gaining carrier receives from the losing carrier for a port to complete—the stage where the losing side has accepted the order and committed to a release day. In Orbit's **Number Porting** lifecycle (above) a request walks `submitted → validating_loa → carrier_review → foc_assigned → foc_scheduled → completed`, so the FOC landing is the point where the estimate becomes a carrier commitment rather than a guess. See the [porting FAQ entry](/reference/faq) that walks the per-stage timeline and the [porting endpoints](/numbers/porting).

***

## G

**Grey Route**
A messaging path that delivers A2P traffic over a channel intended for person-to-person messages — bypassing the destination carrier's commercial agreements, licensing fees, and sender registration — to send at a lower cost than licensed routes allow. Grey routes violate carrier terms and are a primary target of carrier SMS firewalls; traffic caught on one is typically blocked outright, and a sender's reputation on legitimate routes can be damaged too. Orbit sends exclusively over licensed, carrier-approved routes. See the [full definition](https://orbit.devotel.io/glossary/grey-route).

**Group Messaging**
A text conversation shared among three or more phone numbers, where every member receives each message in the thread. SMS and MMS handle the group as a fan-out — the sender posts one copy and the carrier delivers it to each participant, so the group is a naming convenience on top of one-to-one sends. Platforms that thread group conversations, and Orbit's own messaging API and campaign broadcasts, return a delivery receipt per recipient, so an operator can track exactly which members received a given message. Pair with **Bulk SMS** (below) when the goal is one-to-many broadcast without thread semantics; see the [full definition](https://orbit.devotel.io/glossary/group-messaging).

**GPRS (General Packet Radio Service)**
The packet-switched mobile data protocol added to 2G GSM networks — the original always-on data bearer ("2.5G") that carried early mobile internet and MMS media as IP packets next to the circuit-switched voice channel. SMS rides the network's signaling control plane, so SMS delivery to a mobile destination never depends on a GPRS (or any) data bearer — which is why SMS remains the guaranteed-reach channel into markets and devices on legacy coverage long after richer, data-dependent channels become conditional on a capability check. See the [full definition](https://orbit.devotel.io/glossary/gprs).

**Guardrails**
Rules applied to AI agent outputs to ensure compliance, safety, and brand consistency. Enforced inside the agent runtime. Examples: no PII exposure, no profanity, brand voice adherence.

**GSM-7**
The default character encoding for SMS, supporting 128 characters (Latin letters, digits, common punctuation). Messages using only GSM-7 characters fit 160 chars per segment.

***

## H

**Handoff**
The point where a live interaction passes from an **Agent**'s (above) bot to a human — or, in a multi-agent setup, from one agent to an allowlisted downstream agent — with the full conversation context attached. A handoff to a human pauses the bot at the conversation level until control returns; a bot-to-bot handoff starts a fresh run on the receiving agent. See [Handoff targets](/agents/handoff-targets) and the conversation-level pause semantics in [Agent run lifecycle](/concepts/agent-run-lifecycle). See the [full definition](https://orbit.devotel.io/glossary/handoff).

**Human-in-the-Loop / Pending Action (approval gate)**
The four-state gate — `pending → approved | rejected | expired` — that **Orby**'s (see O) tool calls pass through before anything data-changing executes. When a turn invokes a gated tool, the call raises a **pending action**: a durable proposal card naming the tool, the exact validated arguments, and an estimated cost, which an operator approves or rejects before the tool runs; if the proposal's five-minute window elapses without a decision it is cancelled as `PENDING_ACTION_EXPIRED`. Whether a tool must pause is set by its **confirmation policy** — `never` (reads, searches, drafts run inline), `always` (chargeable and side-effecting tools pause at a proposal), or `threshold` (pause only when the estimated cost meets your configured dollar amount) — and a destructive verb in the tool's name (delete, refund, charge, cancel, …) gates it regardless of the declared policy. The hierarchy of approval requirements — an org-wide stance toggled in the Admin Panel under "Approval requirements," where the workspace **owner** enables the gate and picks which high-risk action types mandatory-pause (sender-ID registration, number ports, refunds, data exports, data deletion, campaign launches, subscription changes, template submissions) — defaults to off, and an **operator** acting as themselves is the only person who can resolve the proposals they raised (approvals re-check that identity and the operator's current role at decision time). Every transition — approve, reject, expiry — writes an audit-log event (`orby.tool_action.approved` / `.rejected` / `.expired`) naming the tool, operator, and tenant, so the card's history is replayable. The full model is in [Action approvals: the human-in-the-loop gate](/concepts/action-approvals-model); the error-code playbook lives in [Troubleshooting: Orby pending-action approval](/troubleshooting/orby-tool-approval); and the operator-side workflow is [Using Orby in the dashboard](/guides/orby-in-dashboard). See the [full definition](https://orbit.devotel.io/glossary/human-in-the-loop).

**HLR (Home Location Register) lookup**
A query against a mobile carrier's subscriber database that checks whether a phone number is currently valid, active, and which network it's registered on, without sending the number any traffic. Run before a bulk send to clean a contact list of disconnected or ported numbers and avoid wasted messaging spend. See the [full definition](https://orbit.devotel.io/glossary/hlr-lookup).

**IMSI (International Mobile Subscriber Identity)**
The unique subscriber identifier a mobile SIM carries — the permanent identity an HLR/registry maps onto a subscriber's MSISDN (their phone number) — used for fraud screening and SIM-swap detection rather than routing. See the [full definition](https://orbit.devotel.io/glossary/imsi).

**HMAC-SHA256**
A cryptographic signature algorithm used by Orbit to sign webhook payloads. The signature is sent in the `X-Orbit-Signature` header (or the legacy `X-Devotel-Signature` header for backwards compatibility). See the [Webhook Security guide](/webhooks/security) for verification examples.

**HIPAA (Health Insurance Portability and Accountability Act)**
The US health-privacy statute (its HIPAA Privacy and Security Rules) that governs **PHI** (below) — protected health information — wherever a covered entity or its business associates handle it. Orbit scopes the obligation as a tenant-owned enablement: you attest whether PHI is in scope, execute a **BAA** (Business Associate Agreement — see B) with the platform, and then the HIPAA mode toggle accepts your configuration. Orbit is willing to sign a BAA — see the posture page in [BAA posture](/compliance/baa) and the enablement runbook in [HIPAA enable blocked until the BAA is executed](/troubleshooting/hipaa-enable-baa-not-executed).

**Hunt group (Ring group)**
The legacy PBX term for what Orbit calls a **Ring group** — a list of destinations an inbound call fans out to with a strategy selector (ring-all, sequential, round-robin). On premises PBXs the hunt strategy names (circular, longest-idle, sequential) survive as the ring-group strategy names on Orbit, so a request to "set up a hunt group" maps directly to the ring-groups page under **Voice → Ring groups**. The full mapping plus the worked pattern is in the [PBX operations taxonomy](/guides/ucaas-operations-taxonomy) router and the operator runbook in [Ring groups end to end](/guides/ring-groups).

***

## I

**Idempotency / Idempotency-Key**
The deduplication contract Orbit applies to `POST` requests that create a resource — a message, a call, a contact, a campaign, a top-up — so a retried request can't execute twice. You pass a header named `Idempotency-Key` with a value you choose (a natural identifier like `order-conf-98421` is easier to debug than a random UUID); Orbit stores the completed response against that key for 24 hours. Within that window, the same key with the same body returns the cached response — no duplicate send, no second charge. Three failure shapes to know: omitting the header on a money-moving endpoint returns `IDEMPOTENCY_KEY_REQUIRED`; a malformed key (wrong length or charset) returns `INVALID_IDEMPOTENCY_KEY`; replaying the same key with a different body returns `409 IDEMPOTENCY_KEY_REUSED`. Distinct from SDK-level retry: every Orbit SDK auto-generates an `Idempotency-Key` (UUIDv4) on every non-GET request, so the SDK's own retry loop never duplicates — but a duplicate `POST` without a key creates a second charge or order. Supply your own key whenever retries leave the process that mints the auto key (e.g., a job in your own queue re-run by a worker). See the full contract in [Idempotency and safe retries](/concepts/idempotency-and-safe-retries), the wallet-side collision errors in [Idempotency and billing gates](/troubleshooting/idempotency-and-billing-gates), and the error-code taxonomy in the [Error Code Reference](/reference/error-codes).

**Instagram**
The Instagram messaging channel connects a business to its followers through Instagram Direct Messages via the Instagram Graph API — Orbit handles the OAuth onboarding, page-level permissions, and the inbound webhook fan-in for DMs, story replies, and quick-reply postbacks. Sends to a recipient outside the 24-hour messaging window require a valid Meta message tag or they reject as `MESSAGE_SEND_FAILED`. See the [Instagram channel page](/channels/instagram).

**IP Warmup**
Gradually ramping up email send volume from a new sending IP address, starting with a small daily cap to engaged recipients and increasing it over days or weeks instead of sending at full volume immediately. Mailbox providers have no history to judge a brand-new IP by and treat a sudden burst as spam-like. Orbit's email deliverability API computes and enforces the IP ramp automatically (`GET /api/v1/email/warmup-plan`, `/warmup-status`, `/warmup-enforcement`). See the [full definition](https://orbit.devotel.io/glossary/ip-warmup).

**Domain Warmup**
Same ramp applied to the sending domain (FROM domain) — domain reputation is **DKIM**/**SPF**-bound, so it is portable across IPs and does NOT reset when the sending IP rotates, unlike the **IP Warmup** above. A fresh domain on a warmed IP still starts from a conservative day-1 volume; the repair surface exists on the [email DNS drift](/troubleshooting/email-dns-drift) page rather than the deliverability ramp endpoints. See the **DKIM** and **SPF** entries (below).

**DMARC (Domain-based Message Authentication, Reporting & Conformance)**
The policy layer built on top of **SPF** and **DKIM** (below) that tells receiving mail servers how to handle messages that fail SPF/DKIM alignment, and that reports aggregate results back to the domain owner. The recommended ramp is a policy upgrade from `p=none` (monitor-only) toward `p=quarantine` and finally `p=reject` — never the reverse. DMARC lives in the traffic-light chips the daily DNS check re-validates alongside SPF and DKIM, and the [email DNS-drift troubleshooting](/troubleshooting/email-dns-drift) page covers the drift recovery.

**Jitter**
The variation in packet-arrival delay on a real-time voice or video stream — some packets arrive early, others late — which the receiver smooths with a jitter buffer; sustained jitter past that buffer depletes it and surfaces as choppiness or clipped words callers hear before any packet actually drops. See the [full definition](https://orbit.devotel.io/glossary/jitter) and [Video channel capabilities](/channels/video).

**IVR (Interactive Voice Response)**
The automated phone-menu layer that plays prompts to a caller, collects their answer as **DTMF** (above) key presses or speech, and routes the call on it — to a queue, a **Ring Group** (above), **Voicemail** (below), or a **Handoff** (see H) into an **Agent**. *Orbit behavior:* you build the menu as a visual flow — prompt nodes, a per-digit input gather (or a natural-language utterance, in an NLU menu), and a jump table — then bind it to one of your **DID**s so every inbound call executes your menu instead of a carrier's. The low-code build surface is the [IVR visual builder guide](/guides/ivr-visual-builder) and the add-speech-understanding model is [IVR routing with NLU](/guides/ivr-routing-nlu); when the menu's job is conversation rather than routing, route the call into an **Agent** instead — see the handoff semantics in [Agent run lifecycle](/concepts/agent-run-lifecycle). Also see **Identity Resolution** (below) for the CDP function that folds incoming identifiers onto one profile, and the [full definition](https://orbit.devotel.io/glossary/ivr).

**Identity Resolution**
The CDP function that folds the repeated identifiers of one person — emails, phone numbers, persistent user IDs, and pre-identity anonymous session ids — onto a single contact profile, with merge provenance written onto the survivor so every fold is auditable and reversible. Resolution runs two layers on the same identifier sets: a **deterministic** pass that transitively groups rows equal on a declared normalized key, and a **probabilistic** pass that ranks fuzzy remainder pairs (a respelled phone, a shared non-unique channel id) into a review band for a steward instead of auto-merging. Precedence is tenant-owned per identifier type (`external_id`, `email`, `phone`, `anonymous_id`), as is the auto-merge threshold; every merge returns a `merge_id` with a 30-minute undo window and a durable audit row recording the verdict, the confidence, and the corroborating identifiers. The operator views into the resolved pipeline are the **Identity Graph / Device Graph** (see CDP terms below); the full semantics are in [identity resolution and merge semantics](/concepts/cdp-identity-resolution) and the operator flow in the [Identity resolution guide](/guides/identity-resolution).

**ICCID (Integrated Circuit Card Identifier)**
The 19-digit serial number burned into a SIM — the identifier Orbit's **NaaS Connectivity** index and wallet resolve a SIM by: every lifecycle, usage, quota, and device-lock call on a connectivity SIM addresses `GET`/`POST /numbers/connectivity/sims/{iccid}/...`, and the inventory list returns one row per ICCID. When an order comes in manual mode and the upstream aggregator has not yet assigned one, the platform mints a synthetic ICCID-style identifier so the SIM is addressable from the moment it enters `ordered`. See the [Connectivity SIM model](/concepts/connectivity-sim-model) and the [lifecycle guide](/guides/connectivity-sim-lifecycle).

**IMEI (International Mobile Equipment Identity)**
The 14–16-digit identifier of a mobile *device* (as opposed to its SIM), reported to the network when the device registers. On Orbit's **NaaS Connectivity** SIMs it is the basis of the authorized-device **allowlist**: storing a set of IMEIs on a SIM (`PUT /numbers/connectivity/sims/{iccid}/authorized-imeis`) arms the device lock, and a session that reports an IMEI outside the armed list auto-suspends the `active` SIM and accrues no usage — a theft/diversion guard that holds the SIM at `suspended` until its real hardware checks in; storing an empty list clears the lock back to open. The IMEI observed on each data session is what you inspect when triaging an unexpected suspension. Allowlist management is **tenant-owned**: you decide which devices a SIM may serve. See the [Connectivity SIM model](/concepts/connectivity-sim-model) and the [lifecycle guide](/guides/connectivity-sim-lifecycle).

***

## J

**Jambonz (SIP bridge)**
The session border controller / softswitch edge Orbit deploys to terminate every PSTN call — the SIP element that handles call signaling and asks the platform for the routing decision and verb plan per call. An on-premise or cloud PBX reaches it as a BYOC **SIP Trunk** (above), secure-payment flows bridge capture legs through it, and **Conference** (above) rooms are hosted on it. Distinct from the in-browser **Softphone** (above), which registers against the WebRTC bridge rather than the SBC. See the [Jambonz softswitch model](/concepts/jambonz-softswitch).

***

## K

**Knowledge Base**
The set of documents or data sources a virtual agent may draw on when answering a question. A knowledge base usually holds help articles, product documentation, policies, and FAQs, and the agent retrieves relevant passages from it at run time to ground its reply in your content rather than in the model's general training.

**In Orbit,** an agent's knowledge base is indexed in the knowledge pipeline and retrieved per run as RAG (retrieval-augmented generation) — the agent pulls the matching chunks for the current question and composes its answer from them. Knowledge bases are attached to agents from the dashboard under Agents, or via the public knowledge API. See the [knowledge-pipeline concept](/concepts/knowledge-pipeline) and [Agents](/agents/overview).

**KakaoTalk (Alimtalk / Friendtalk)**
Korea's dominant messaging app, reachable through Orbit's KakaoTalk Biz Message gateway. Two message classes matter: **Alimtalk** — the notification-template lane (order confirmations, OTPs, appointment reminders) sent through pre-approved templates — and **Friendtalk** — the promotional lane, which requires no template approval but carries marketing-only rules. Both deliver into the same Kakao channel from one unified send surface. See the [Kakao channel page](/channels/kakao).

**KYC (Know Your Customer)**
The once-per-organization identity review that verifies *the business itself* — the company name, country, website, use case, beneficial owners, and address of record a reviewer can sanction-screen — rather than any single phone number (per-number document bundles are the separate **Compliance Profile**, see C). Organization KYC is one of the two hard gates on live traffic in the [Quickstart](/quickstart#step-5-go-live) (the other is a funded balance): until a review lands `approved`, buying numbers stays open but no SMS, WhatsApp, or voice message leaves the platform, and the dashboard banner and **Settings → KYC** page both read the same status endpoint (`GET /api/v1/organization/kyc/status`, statuses `not_started → pending_review → approved | rejected`). A rejected submission is re-submittable with amended details — it is never a terminal block. KYC is a tenant-owned control: you assemble and submit the profile; Devotel operations reviews it. Walk the submit–poll–resubmit loop in the [organization KYC/KYB/IDV onboarding guide](/guides/organization-kyc-onboarding).

***

## L

**Least-Cost Routing (LCR)**
The per-organization route-ordering policy that picks which upstream carrier path an outbound SMS egresses on — ranking the Devotel wholesale trunk and your connected BYO carriers per destination on cost, delivery quality, live bind health, and a sticky bonus for the route that most recently delivered. The failure it prevents: a congested or degraded route keeps drawing traffic — with sticky routing active, a route whose health drops loses its incumbency bonus and stops being picked until it recovers. LCR runs **after** sender resolution, so it decides *which carrier path* a message takes, not *which sender it goes out from* — that sender-identity step is in [Sender & Routing](/concepts/sender-and-routing), and the throughput caps on the chosen path are separate (**Throughput**, above). Preview the ranked routes with the dry-run `GET /api/v1/messaging/lcr/route-quote` and manage the policy with the `GET` / `PUT /api/v1/messaging/lcr/policy` endpoints under the [Messaging API](/api-reference/endpoints/messaging); the scoring inputs and configuration patterns are in [Least-cost routing policy](/concepts/least-cost-routing).

**LLM (Large Language Model)**
The AI model powering agent conversations. Orbit is Anthropic-only — all LLM requests route through a single partner-vetted Anthropic Claude gateway (`claude-opus-4-7`, `claude-sonnet-4-6`, `claude-haiku-4-5-20251001`, `claude-fable-5`). Tenants do not connect their own model-provider keys. An agent pinned to `claude-fable-5` runs on `claude-opus-4-7` at request time.

**Live Chat**
The real-time, session-based conversation channel a website or app visitor opens to reach a human agent (or an AI assistant first) without a phone call or an email wait — delivered over **WebSockets** rather than a carrier channel, and landed in the same shared inbox as SMS, WhatsApp, and email conversations. A **Chatbot** or **Agent** (above) can take the first turn and hand off to a human with the full transcript, and **Cobrowse** (above) extends the session into guided page-sharing. See the [full definition](https://orbit.devotel.io/glossary/live-chat).

**LOA (Letter of Authorization)**
The signed mandate a customer issues to authorize a phone-number port: the document that says "transfer this number from the losing carrier to the gaining carrier" and gives the carrier permission to act on it. In Orbit's porting flow the signed LOA uploads early — the lifecycle first step past `submitted` is `validating_loa` before carrier review — and a rejected or expired LOA is the single most common hold point in a port. See the [porting FAQ](/reference/faq) for the stage detail and the [porting endpoints](/numbers/porting).

**LINE**
The LINE messaging channel reaches LINE app users through Orbit's LINE integration — fully multi-tenant: Orbit resolves the receiving tenant from the LINE channel ID on every inbound event, so multiple organizations run their own LINE bots on the same platform. Inbound messages arrive on your registered webhook with the standard Orbit inbound envelope (`channel: "line"`). See the [LINE channel page](/channels/line).

**Long Code**
A standard-length telephone number — ten digits plus the country code in North America — used for two-way messaging and voice, as opposed to the five-to-six-digit short code. Long codes look like ordinary phone numbers to the recipient, and they support person-to-person traffic by default while application-to-person (A2P) traffic on them requires carrier registration in the United States.

**In Orbit,** US A2P messaging runs on 10DLC-registered long codes — brands and campaigns are registered through The Campaign Registry (TCR) so carriers accept the traffic and apply the higher registered throughput. See [10DLC registration](/guides/10dlc-registration).

**Loyalty Engine (points accrual)**
The tenant-configured points layer that credits and debits a CDP contact's loyalty balance as campaigns execute. In Orbit the points-accrual surface is a pure, deterministic engine the dashboard's **Audience → Loyalty** surface configures: behavioural events earn points per the program's rules, redemptions burn them, and a contact's balance and tier are a projection over the CDP event stream — event-sourced, with no separate loyalty table to migrate. FIFO expiry applies: each earn is a lot that expires after a configured window, redemptions consume the oldest live lots first, and tier follows lifetime earned points, so spending the balance never demotes the member. This is distinct from **Net Promoter Score** (below), which measures survey-loyalty, and from the agent-gamification leaderboard, which scores internal QA/queue agents rather than end customers.

**Incentive fulfillment** is the settlement side of the same surface: incentives (a support credit, a win-back reward, a one-off promo) are issued, listed, redeemed, and voided as an append-only event ledger whose current state is folded on read; fulfillment is the tenant-owned settlement step that disburses the reward via the [Incentive endpoint](/api-reference/endpoints/incentives). Ownership follows the tenant-control convention: the tenant authors the accrual rules and the payout policy (earn rules, expiry windows, tier ladders), and the platform executes them. See the [full definition](https://orbit.devotel.io/glossary/loyalty-engine).

***

## M

**MCC/MNC (Mobile Country Code / Mobile Network Code)**
The pair of numeric codes that together identifies a mobile subscriber's country (MCC) and specific carrier network (MNC) — for example, which network a phone number is currently registered on. A [Number Lookup](/numbers/lookup) over the HLR or a carrier-data API returns the MCC/MNC pair alongside line type and portability status, rather than guessing it from the number's dialing prefix. Routing on a stale pair — a number that has ported since it was last checked — is a common cause of misrouted messages and inflated delivery costs; per-country carrier rules matter too (see [country capabilities](/numbers/country-capabilities)). See the [full definition](https://orbit.devotel.io/glossary/mcc-mnc).

**MCCMNC**
The concatenated MCC+MNC record key that billing and pricing use when referring to one destination operator — a single string like `26201` (MCC `262` for Germany + MNC `01` for Deutsche Telekom). Per-operator rates and per-operator overrides are keyed on this value; tenants add carrier-specific rate overlays in Billing → MCCMNC overrides ([Pricing & rate resolution](/concepts/pricing-rate-resolution), [Billing API — mccmnc-overrides](/api-reference/endpoints/billing)).

**Messenger (Facebook Messenger)**
The Facebook Messenger channel carries text, media, quick replies, and message tags through the Meta Graph API. Orbit connects a Page via OAuth and fans inbound DMs and postbacks into your webhook; **sender personas** (named agent identities) render a per-send identity to the recipient instead of the Page silhouette. A send outside the recipient's 24-hour messaging window requires a valid Meta message tag (OTN tokens extend that reach once per recipient). See the [Messenger channel page](/channels/messenger).

**MSISDN (Mobile Station International Subscriber Directory Number)**
The E.164 phone number that identifies a mobile subscriber on their network — the number a customer dials and that carriers bill against, as distinct from the **IMSI** (below), which is the permanent SIM identity an HLR/registry maps onto a subscriber's MSISDN. A [Number Lookup](/numbers/lookup) resolves an MSISDN to its current carrier (**MCC/MNC**, above), line type, and portability status before a send commits to a route — see the [full definition](https://orbit.devotel.io/glossary/msisdn).

**Messaging Tier (WhatsApp Messaging Tier)**
Meta's per-WABA daily cap on business-initiated conversations — how many unique customers your WhatsApp Business Account may start a conversation with inside a rolling 24 hours, independent of your per-second **Throughput** (below). Meta assigns the account to a tier — 1K, 10K, 100K, or unlimited recipients — and raises it as quality and volume history accumulate, so the ceiling is earned rather than configured. Sending past the current tier returns `WHATSAPP_TIER_LIMIT_EXCEEDED` on the [rate-limit taxonomy](/concepts/rate-limit-and-cooldown-taxonomy); the right reaction is to slow the campaign rather than retry in a tight loop. Sustained high quality posture together with a growing base of 24-hour-initiated conversations is what moves an account up a tier — a degraded **Quality Rating** (below) is what drags it down. See the [WhatsApp channel page](/channels/whatsapp) for onboarding and per-WABA posture.

**Message queue (inbound dispatch queue)**
The platform-side hold lane a send waits in before dispatch to a provider — distinct from any queue a downstream carrier or gateway keeps after it accepts the submission. An Orbit send parks in this pre-dispatch lane while **Throughput** (see T) caps, sender-pool warm-up, provider connectivity, or a scheduled `send_at` gate it, and the row reads `queued` on the **Message Status Lifecycle** (below) until the handoff. Work the cause table on the [queued-hold page](/reference/troubleshooting) and the sister [message-queued triage](/troubleshooting/message-queued); the transition rules the lane entry respects are on the [message-status DAG](/concepts/message-status-dag).

**Message Status Lifecycle (queued, sent, delivered, undelivered, failed, expired, submitted\_no\_receipt)**
The ordered set of statuses an outbound message moves through from acceptance to final outcome — the vocabulary every row in your Delivery Log and every `message.*` webhook event carries, and the first diagnostic vocabulary for any "where is my message" question. `queued` means the hold is platform-side — the row has not been handed to a sender or provider yet, so work the [message-queued triage](/troubleshooting/message-queued) and the [enqueued-empty-states checklist](/troubleshooting/enqueued-empty-states). `sent` means the provider or carrier accepted the submission. `delivered` means the handset receipt came back confirmed. `undelivered` means the carrier attempted delivery and the handset could not take it; `failed` means a dispatch-time or classified carrier failure with retries exhausted — decode both on [Message undelivered or failed](/troubleshooting/message-undelivered-failed). `expired` means a receipt arrived past the late-arrival window and no longer counts. `submitted_no_receipt` is the provisional sentinel — submission accepted, no receipt yet, `is_terminal: false` — so a genuine receipt that lands afterward still supersedes it (see [Sent with no receipt](/troubleshooting/submitted-no-receipt)). Transitions are enforced by an allowed-transition DAG with weighted precedence, so out-of-order receipts resolve to one answer instead of corrupting the record — and the operator-driven `cancelled` state is an absolute floor no carrier callback can move. The status ladder and precedence rules are on the [message-status DAG](/concepts/message-status-dag), the per-status semantics on the [delivery lifecycle](/concepts/delivery-lifecycle), and the [full definition](https://orbit.devotel.io/glossary/message-status).

**Messaging Service**
A named sender container that binds a default sending identity plus per-message settings (`status_callback`, `validity_period`) — the Twilio Messaging Service parity object. Pass `messaging_service_id` on a send and the service's sender fills in only when you don't pass a sender yourself; the service sits in the `from → sender_pool_id → messaging_service_id` resolution chain alongside a direct sender and a **Sender Pool** (above), and a wrong or missing reference surfaces as the `SENDER_REQUIRED` error. Service-level send-rate caps are enforced per service as `MESSAGING_SERVICE_MPS_EXCEEDED` (see **Throughput** below). See [Sender resolution](/concepts/sender-resolution), the [Messaging Services API](/api-reference/endpoints/messaging-services), and the [sender chain concept](/concepts/sender-and-routing).

**MX record (Mail Exchange record)**
The DNS record type that proves a domain can receive email — the host a sending platform asks before it even attempts to open the SMTP connection. Orbit's `VERIFY_EMAIL_UNDELIVERABLE` pre-send guard resolves the recipient domain's MX first: no MX, no send attempt, no wallet deduction. A domain that publishes no MX record is provably undeliverable at the network level, so the guard rejects the send instead of paying for a route it already knows will fail. See the [email DNS-drift troubleshooting](/troubleshooting/email-dns-drift) page and the `VERIFY_EMAIL_UNDELIVERABLE` failure shape in [Error codes](/reference/error-codes).

**MNP (Mobile Number Portability)**
The mechanism that lets a subscriber move an **MSISDN** (above) from one carrier to another while keeping the same phone number — once a port completes, the prefix-hint-derived route breaks and the number's actual carrier is no longer the one its digits imply. Marking that migration is the whole job of the lookup stack: **Number Porting** (see N) moves a number *you own* between carriers over the [porting flow](/numbers/porting) — from Orbit's side an inbound port lands on the Devotel wholesale fabric, so the fabric routes traffic to the newly-ported number directly without any donor-carrier dip of its own — while [Number Lookup](/numbers/lookup) tells you whether a *destination* mobile number has ported, on the same "which carrier actually hosts this number now" family as **RND (Reassigned Numbers Database)** (below), which tracks disconnected-and-reassigned identities rather than between-carrier moves. A lookup returns `ported: true` plus the current carrier's **MCC/MNC** (above), `mnp_original_carrier` naming the donor (or `carrier-original-mnp`), and `portedDate` — the migration guide's HLR/lookup cross-read pattern in [Migrate from Infobip](/guides/migration-from-infobip) routes on that current carrier, and a ported-flag spike in a dead-on-arrival outbound log usually means stale carrier data a lookup would have refreshed. See the [full definition](https://orbit.devotel.io/glossary/mnp).

**MO/MT (Mobile Originated / Mobile Terminated)**
The direction a message travels relative to the mobile network: an MO message is sent FROM a handset (a customer texting in), an MT message TO a handset (a business notification or reply). Carriers price, filter, and rate-limit the two directions differently, and an inbound webhook fires on MO — so when a reply isn't recording or routing, naming the direction is the first diagnostic step. See [Inbound message resolution](/concepts/inbound-message-resolution) and the [inbound MO routing troubleshooting](/troubleshooting/inbound-sms-no-route), plus the [full definition](https://orbit.devotel.io/glossary/mo-mt). Cross-read against the combined **MO/MT direction primer** entry (see P), which aligns the pair with **P2A / P2P / A2P**.

**MMS (Multimedia Messaging Service)**
The image/audio/video counterpart of SMS — one long code serves both channels: media you send on the REST API uploads as an attachment and the carrier delivers it inline rather than as a link, so a product photo or a boarding pass arrives in the message thread itself. *Orbit behavior:* MMS rides the same `POST /api/v1/messages` send API and the same DLR/webhook lifecycle as SMS (the segmented-attention rules don't apply — MMS bills per message, not per **Segment**, and there is no GSM-7/Unicode encoding split), and sends over the same licensed, carrier-approved routes — carrier approval in the US still runs through the **10DLC** registration on the sending number. Availability is gated by the number's `mms` capability (see [country capabilities](/numbers/country-capabilities)) and by the destination carrier accepting media at all — where it doesn't, the channel degrades to SMS with the media link appended. Check what a destination can receive before you attach media with [Number Lookup](/numbers/lookup), and see the channel surface in the [MMS channel page](/channels/mms), the segment mechanics it skips in [SMS segments & encoding](/concepts/sms-segments-and-encoding), and the [full definition](https://orbit.devotel.io/glossary/mms).

**MCP (Model Context Protocol)**
The open protocol an **Agent** (above) uses to call external tools — and, in the other direction, the protocol an external MCP client (Claude, ChatGPT, an IDE agent) uses to operate your tenant through Orbit's hosted MCP server. When you register an MCP server for an agent, the server URL passes a write-time SSRF guard: a non-HTTPS scheme, a loopback/private/link-local address, an internal-only hostname, or a DNS record that resolves to one is refused as `422 INVALID_MCP_SERVER_URL` (the OAuth grant's `token_url` is validated identically as `INVALID_MCP_OAUTH_TOKEN_URL`), the same public-FQDN class of check the **Webhook** (below) and **SIP Trunk** (above) registrations run; server names are unique per agent, so a collision returns `409 MCP_SERVER_NAME_CONFLICT`. See the [hosted MCP server model](/concepts/mcp-hosted-server) and the client setup walkthroughs in the [MCP server handshake guide](/guides/mcp-server-handshake).

**MNO (Mobile Network Operator)**
The carrier that owns the radio spectrum and physical infrastructure — the towers, the licensed frequency bands, and the core network — that a mobile subscriber connects to. An MNO issues its own SIM cards and IMSIs, operates its own **MCC/MNC** (above), and controls the quality of service end-to-end. In Orbit, when you purchase a NaaS/eSIM data plan, the `providers` catalog in `GET /eSIM/plans` surfaces which MNO owns the underlying network for each plan — so you know whether you are buying directly from a tier-one carrier or from a reseller. See [Connectivity and the SIM model](/concepts/connectivity-sim-model) for the network-ownership taxonomy.

**MVNO (Mobile Virtual Network Operator)**
A carrier that resells connectivity on an **MNO**'s (above) network without owning the radio spectrum or towers itself — it buys wholesale access from one or more MNOs and sells branded plans to its own subscribers under its own commercial terms. An MVNO issues its own SIMs but the IMSI still resolves back to the host MNO's **MCC/MNC** (above). In Orbit, the NaaS/eSIM plan catalog distinguishes MVNO-hosted plans from MNO-direct plans so you can choose based on coverage, price, and the underlying network operator. See [Connectivity and the SIM model](/concepts/connectivity-sim-model).

**MVNE (Mobile Virtual Network Enabler)**
The infrastructure middle layer that sits between an **MNO** and an **MVNO** (both above) — the MVNE runs the provisioning, billing, and OSS/BSS stack that the MVNO needs to operate, so the MVNO can focus on brand and go-to-market without having to build its own core network integration. In Orbit, when an MVNO plan lists an MVNE as its enabler, the `providers` object in the eSIM plan catalog includes the MVNE's identity alongside the host MNO's; the distinction matters for support routing and provisioning SLAs. See [Connectivity and the SIM model](/concepts/connectivity-sim-model).

***

## N

**NaaS (Numbers & Network as a Service)**
The numbering pillar — the hosted inventory and lifecycle of the phone numbers all other pillars address. Reserve, purchase, port, release, or park a number; register it on 10DLC, toll-free, or a country-specific framework; and let the platform gate the whole lifecycle. NaaS pairs with the **Sender ID** (see S) terms — one addresses (NaaS), one identifies (Sender) — and with **CPaaS** (see C): the address-pool sits beneath the APIs. On Orbit, NaaS is the [number lifecycle concept](/concepts/number-lifecycle) and the six-state status map, plus the porting practice in [Number portability model](/concepts/number-portability-model) and the purchase-to-release flow in [Billing and numbers renewal model](/concepts/billing-and-numbers-renewal-model).

**NPA/NXX (Numbering Plan Area / Central Office code)**
The two geography codes that form the first six digits of a NANP (US/Canada) phone number: `NPA` is the three-digit area code and `NXX` the three-digit central office (exchange) code, together preceding the four-digit line number. `NXX` digits 2–9, and some `NXX` combinations — most notably N11 service codes such as `911` — are reserved. The pair matters for local-presence planning (matching the region your customers dial) and for porting scope. See [country capabilities](/numbers/country-capabilities) for region coverage and **Number Porting** (below) for the move itself.

**NDC (National Destination Code)**
The country-level routing code inside an E.164 international phone number — the two-to-three-digit segment that follows the country code and identifies the destination network or service area within that country, before the subscriber digits. It sits above the pair of geography codes the NANP spells out explicitly: in US/Canada numbers the NDC resolves further into the **NPA/NXX** (above) pair, while other numbering plans carry the NDC as a single segment. Either way, **Number Lookup** maps that segment to a carrier: a lookup resolves a number to its **MCC/MNC** network codes, line type, and portability status before a send commits to a route. See the region coverage on [country capabilities](/numbers/country-capabilities).

**NAT (Network Address Translation)**
The technique a router or firewall uses to let many devices on a private network share one public IP address, rewriting the source address and port on outbound packets and reversing the change on the way back. NAT breaks the private address a SIP or WebRTC endpoint embeds inside its own signaling, which is why real-time voice and video need **STUN / TURN / ICE** (below) to find a reachable public address before media can flow — see the [full definition](https://orbit.devotel.io/glossary/nat).

**STUN / TURN / ICE**
The three protocols a **WebRTC** (below) endpoint uses to get media through **NAT** (above): STUN (Session Traversal Utilities for NAT) discovers the public address and port the NAT assigned; TURN (Traversal Using Relays around NAT) relays media through a public relay server when no direct path between the endpoints works; ICE (Interactive Connectivity Establishment) is the candidate-pairing algorithm that gathers STUN and TURN candidates and picks the best working path. Orbit runs a regional coturn TURN fleet so a relayed call stays short — see [Media region routing](/concepts/media-region-routing) — and when a call lands on a TURN relay path, the [video call quality troubleshooting](/troubleshooting/video-call-quality) page is the place to start.

**NPS (Net Promoter Score)**
The loyalty metric derived from a single-question "how likely are you to recommend us" survey, scored 0–10 and bucketed detractors / passives / promoters — collected through the [survey endpoints](/api-reference/endpoints/surveys) alongside **CSAT** (above) and delivered via `survey.response` webhooks in the [webhook reference](/reference/webhook-events).

**Number Masking**
A privacy-proxy session that lets two parties exchange SMS and calls through a shared proxy number without seeing each other's real phone number — the ride-share (driver and rider), delivery (courier and customer), marketplace (buyer and seller), and healthcare (provider and patient) pattern where both sides must reach each other and neither should walk away with the other's personal contact information. You create a session with the two participants' E.164 numbers and an optional TTL; Orbit claims a pool number, binds it to the session, and forwards traffic between the parties until you close the session explicitly or the TTL elapses and a scheduled sweep expires it — and the proxy number returns to the pool either way. See [Number masking](/numbers/masking) and the end-to-end [masking sessions guide](/guides/number-masking-privacy-sessions).

**Number Porting**
Moving a phone number from one carrier or provider to another while keeping the same number, so customers and saved contacts keep working. Porting lets an organization change its provider without publishing a new number and is the normal route for adopting a new CPaaS platform with an established number inventory.

**In Orbit,** number ports are initiated from the dashboard under Numbers: you submit the current carrier's account information, Orbit coordinates the port with the losing carrier, and keeps the current provider's route live until the cutover so inbound traffic is not interrupted. See [Phone numbers](/numbers/overview).

**Notify / Unified Delivery Cascade**
The cross-channel completion receipt Orbit returns for a `POST /api/v1/notify` send — every hop of the fallback chain stamps the same `notify_id`, and `GET /api/v1/notify/:notifyId` reconstructs the whole chain to answer *did any hop reach this recipient?* with one call, reporting whether fallback legs are still pending and applying the channel-aware delivered predicate. Distinct from the per-channel **DLR** (above) events, which update one hop's own message row as each carrier confirms: the `notify_id` receipt is the cross-channel aggregate over those hops, while the per-hop `message.*` events are the drill-down. An id stamped on no message row in your tenant returns `404 NOTIFY_NOT_FOUND`. See the [Track a cascade guide](/guides/track-a-cascade), the cascade semantics in [Cascade failover policy](/concepts/message-cascade-groups), and the FAQ entry in the [FAQ](/reference/faq).

***

## O

**OCN (Operating Company Number)**
The four-digit code NECA assigns that identifies a carrier — which carrier holds or receives your number on a port. When you move a number off Orbit to another provider, pass that provider's OCN in the `target_carrier_ocn` field of the port-out request to tell Orbit which carrier is claiming it. See the worked example in the [port-out FAQ entry](/reference/faq), the ownership model in the [number-port-out model concept](/concepts/number-port-out-model), and the **CLEC** entry (above) for the carrier class that most often owns an OCN.

**Origination / Termination**
The wire direction of a voice call or SMS, named from the network's side of the hop: **origination** is traffic entering the telephony network (the caller's side of the call, or a handset's SMS to a number) and **termination** is traffic delivered onto it (the callee's side of the call, or an SMS delivered to a handset). The voice and messaging siblings of the same idea are **MO/MT** (above): MO maps to origination, MT to termination — carriers price and regulate each direction separately, which is why an inbound US rate card lists origination while outbound pricing lists termination. On Orbit, inbound flows resolve through [Inbound message resolution](/concepts/inbound-message-resolution) and the per-direction capability matrix in [country capabilities](/numbers/country-capabilities).

**OTP (One-Time Password)**
A short-lived, single-use code that proves a user controls a phone number or an email address, most commonly six digits. Users receive one during sign-in, transaction confirmation, or account recovery, and replaying it after it has expired or been consumed is rejected by the verification system.

**In Orbit,** the Verify product pillar generates and checks one-time passwords across SMS, WhatsApp, voice, flashcall (SNA), and email. Each verification carries a configurable attempt maximum and a resend-cooldown window, and the send and check endpoints are described in the verification lifecycle. See [Verify](/verify/overview) and the [verification lifecycle](/concepts/verification-lifecycle).

**Opt-In / Opt-Out**
The process by which a recipient consents to (opt-in) or withdraws from (opt-out) receiving messages. US regulations require explicit opt-in for marketing messages, and carriers enforce a standard keyword set on SMS: `STOP` (or `UNSUBSCRIBE`) withdraws consent, and `START` (or `UNSTOP`) re-grants it. A STOP reply on Orbit writes an opt-out against the contact with channel scope `all` and propagates it across every channel reachable on that address — the recipient is dropped pre-send from campaigns, contact imports, and API dispatches alike, and receives a confirmation telling them to reply `START` to re-subscribe. The per-channel entry points differ: SMS and WhatsApp opt-outs arrive as keyword replies, while an email opt-out arrives as an unsubscribe click — and all three converge on the same tenant-owned **Suppression list** (below). Manage named opt-out lists over the [Opt-Out Lists API](/api-reference/endpoints/opt-out-lists), record and audit consent directly through [consent management](/compliance/consent-management), and read the full mechanics — including bulk CSV import and the re-consent path — in [Opt-Out & Suppression Lists](/compliance/opt-out-suppression). See also the [MessageSuppression API](/api-reference/endpoints/messagesuppression) for the flat per-address suppression endpoint..

**Double Opt-In**
The confirm-reply variant of an **Opt-In** (above): instead of counting one declaration — the recipient typing their number onto a web signup form or checking a signup box — as the full grant, the recipient first receives a confirmation prompt and must answer back affirmatively before consent exists. Single opt-in treats the capture itself as the grant; double opt-in treats the capture as a *request* and the reply as the grant. Regulators and carrier reviewers (TCPA express written consent, GDPR confirmed opt-in, 10DLC campaign review) grade the evidence quality, and the two-event artifact — prompt sent, reply received — survives a dispute a single form write cannot. The handoff between your web signup form and the SMS or email confirmation runs through the **[double opt-in handshake](/compliance/double-opt-in)**: the begin call records a `pending` row and returns the confirmation-prompt copy, and the recipient's YES reply (or the click on the email confirm link) promotes the pair to a confirmed `opted_in` grant. Until the reply lands, the pair sits in a do-not-send window: a `pending` handshake records intent without unblocking sends — it is deliberately not a consent grant — so your send must wait for the confirmed state before it counts as consented traffic. The capture surfaces that drive the handshake are your own — a web signup form, an SMS keyword (`JOIN`), a WhatsApp pre-approved template, an email capture form — each with the matching disclosure wording beside the capture point from the [opt-in disclosure templates](/compliance/opt-in-disclosure-templates). Confirmed grants land in the same consent ledger every other surface reads — see the [consent and suppression model](/concepts/consent-and-suppression-model) for how grants and **Suppression list** (below) entries compose, and cross-read **Opt-In / Opt-Out** (above), **Consent Receipt** (C section), and the **DNC / DND Registry** (D section) entries for the neighboring gates. Tenant-owned: you run the capture and the confirmation prompts; Orbit records the pending row, the reply, and the confirmed grant.

**Omnichannel capacity reservation**
The atomic slot hold that stops an inbound interaction from being double-booked onto an agent who answers both voice calls and digital conversations. Each agent carries a tenant-configurable ceiling of blended slots (one for a live voice call, one per open digital conversation), and before either the voice dispatcher or the inbox router assigns work it must reserve a slot against that ceiling — a refusal re-routes to the next eligible agent, an overflow queue, or the unassigned pool. The hold is short-lived (released once the assignment lands, and expires on its own after a few dozen seconds) and governs inbound assignment only. See the full model in [Omnichannel capacity and reservation](/concepts/omnichannel-capacity-reservation).

**Orby (Operator Assistant)**
The operator-facing assistant built into the Orbit dashboard — a chat panel scoped to the signed-in operator's organization and role that answers workspace questions ("how many conversations are unassigned?"), points operators at the right setting ("where do I set quiet hours?"), and proposes data-changing actions behind an explicit approval card. Orby authenticates via dashboard session only — an API-key call is rejected with `403 ORBY_SESSION_REQUIRED` — so every turn carries a concrete operator identity. It is deliberately not an **Agent** (see A): an AI agent talks to your customers, while Orby serves the people running the workspace and never takes a customer-facing turn. On a degraded backing store the public past-chats list degrades to an empty list instead of erroring, and nothing is deleted by that degraded view. See the [architecture concept](/concepts/orby-operator-assistant), the operator workflow in [Using Orby in the dashboard](/guides/orby-in-dashboard), and the endpoint contract in the [Orby API reference](/api-reference/orby).

***

## P

**PHI (Protected Health Information)**
Any individually identifiable health-related data — a patient's diagnosis, treatment record, insurance details, or any identifier attached to health status — that **HIPAA** (see H) governs. On Orbit, PHI is what the **BAA** (see B) unlocks: until an executed BAA is on file, a contact-list or segment you designate as PHI-adjacent blocks campaign launches against it with `422 HIPAA_BAA_REQUIRED`, and the HIPAA mode toggle itself refuses to enable. Marking an audience as PHI-adjacent and lifting designations are tenant-owned decisions. See the launch gate in [HIPAA\_BAA\_REQUIRED](/troubleshooting/phi-audience-baa-required) and the compliance posture in [BAA posture](/compliance/baa).

**PSAP (Public Safety Answering Point)**
The dispatch center an emergency call routes to — the destination **E911** (see E) selects from the caller's registered address so the right responders get dispatched. On Orbit, outbound voice calls to an emergency short code are rejected pre-flight with `422 EMERGENCY_CALLING_NOT_SUPPORTED` — a platform hard guard with no tenant toggle — so dial emergency services from a regular mobile or landline phone. See [Emergency calling](/voice/emergency-calling) for the full behavior and operator obligations on softphone surfaces.

**PDD (Post Dial Delay)**
The elapsed time between dialing a call and hearing ringback tone or the call connecting at the far end. PDD is a setup-phase metric driven by SIP signaling across the carriers between origination and termination, not by the audio path — consistently high PDD is a common early sign of a congested or poorly-routed voice trunk.

**Passkey (WebAuthn)**
A device-bound credential on the **Verify** service that replaces a readable code with a signed challenge — the device answers with biometrics or a device PIN, and no phishable code ever transits. That makes it phishing-resistant by design: the credential only signs for the origin (domain) it was registered with, so a lookalike page cannot collect a usable response, unlike the **OTP** (above) or **Flashcall** (above) code fields an attacker can trick the user into reading back. Distinct from a TOTP authenticator code, where the user still copies a code out of an app and reads it back to an attacker who asks. Orbit ships it as one of the Verify factor channels next to OTP, flash call, SNA, and TOTP. See [Verify](/verify/overview) and the [full definition](https://orbit.devotel.io/glossary/passkey).

**PECR / UK e-Privacy (Privacy and Electronic Communications Regulations)**
The UK's electronic-marketing statute (the Privacy and Electronic Communications Regulations 2003, enforced by the ICO) — the e-privacy regime that sits **alongside** UK GDPR and separately governs whether the message itself — a marketing call, text, email, or push notification — was one you were allowed to send before you had consent. For marketing, PECR is largely an **opt-in** regime: consent comes first and has to be documented, with TPS/CTPS (Telephone Preference Service) screening layered on for voice. Like **CASL** (C section) and unlike a platform gate, meeting PECR is a **tenant-owned** burden — Orbit supplies the consent posture knobs, the DNC scrub, the suppression layer, and the recording announcement. Map each obligation to the surface you have in the [UK PECR & e-Privacy guide](/compliance/uk-pecr-eprivacy).

**Port-Out / Losing Carrier**
The reverse of **Number Porting** (above): moving a phone number you host on Orbit over to another carrier, making Orbit the losing carrier — and the requesting carrier the gaining one. The residual risk is theft-by-port (slamming/SIM-swap-adjacent fraud), so a port-out only proceeds after the subscriber authorizes the transfer with their current-carrier credentials (in the US, CPNI — Customer Proprietary Network Information — rules govern what account data a carrier can demand and share for validation): freeze outgoing ports while you verify the request genuinely came from the customer, and release only after the gaining carrier's validate-ack cycle checks out. The port-in flow's LOA/FOC mechanics in the [porting guide](/numbers/porting) apply symmetrically when you're on the losing side, and the per-rejection recovery runbook is [Troubleshoot port-out rejections](/troubleshooting/port-out-blocked).

**Packet Loss**
The share of media packets that never arrive on a real-time voice or video stream — unlike **Jitter** (above), which makes packets merely late, loss makes them missing, so the buffer can't smooth it and audio/video drops out or sounds robotic. See the [full definition](https://orbit.devotel.io/glossary/packet-loss).

**PBX (Private Branch Exchange)**
The phone system a business runs to route calls inside its own organization — extensions, ring groups, call queues, voicemail — connecting to the **PSTN** (below) and to carriers through a **SIP Trunk** (below) rather than physical phone lines in the cloud-PBX model. See the [full definition](https://orbit.devotel.io/glossary/pbx).

**PSTN (Public Switched Telephone Network)**
The worldwide circuit-switched telephone network — the legacy trunk infrastructure actual calls terminate onto when a connection lands off-net. **PBX** (above) is the premises side and **SS7** (below) carries its call signaling. See the [full definition](https://orbit.devotel.io/glossary/pstn).

**Presence (Agent Presence)**
The five-state machine that every contact-center routing decision reads first — `available`, `busy`, `wrapup`, `paused`, `offline` — recorded per queue membership and folded into a single worst-case state by severity (`busy > wrapup > paused > offline > available`) by dispatch, the omnichannel capacity ledger, and supervisor wallboards. Dispatch only rings `available`; movements come from login, aux (pause/away) codes, wrap-up windows, and call assignment, with the softphone's four-value toggle mapping `away → paused` at the storage boundary. Presence gates what **Dialer** (above) and queue dispatch may deliver to the agent at all. See the state table and the per-edge movers in the [agent presence lifecycle concept](/concepts/agent-presence-lifecycle).

**Presence Federation**
The per-user opt-in that folds availability from the tools a person already works in — Microsoft Teams, Slack, Cisco Webex, Zoom, and Google or Microsoft 365 calendars — into their Orbit presence, on a most-busy-wins merge: a federated source can only make you appear busier, never less busy, and the status you set yourself always outranks federation. An org admin authorizes each provider once for the organization (one OAuth grant covers everyone); each person then turns sources on or off under **Settings → Presence**, where degraded grants surface as **Reconnect required** badges with the fix. See the [presence federation guide](/guides/presence-federation-settings) for setup and the [degraded-state decoder](/troubleshooting/presence-federation-states) for every sync-failure state.

**P2A (Person-to-Application)**
The inbound direction of two-way messaging: a consumer initiates contact with a business application — a keyword text-in (JOIN, STOP), an inbound support request, or a channel reply on SMS, WhatsApp, or RCS. In the **MO/MT** (above) vocabulary a P2A message is always MO (mobile originated). In Orbit, every channel's P2A traffic lands in the shared team inbox, and inbound webhook handlers let you automate on the inbound trigger. See the [full definition](https://orbit.devotel.io/glossary/p2a-messaging) and [Inbound message resolution](/concepts/inbound-message-resolution).

**P2P (Person-to-Person)**
Messaging traffic between two people sending to each other, as opposed to A2P (Application-to-Person) traffic, where an application sends messages to people. Carrier rules, sender requirements, and throughput limits differ sharply between the two classes, so platforms classify traffic before routing it.

**In Orbit,** outbound messaging is treated as A2P traffic by default and routed accordingly — the conversational (P2P-style) two-way inbox route is the exception rather than the rule. The MO/MT direction primer below lays out the P2P / A2P / P2A taxonomy in full; see the **MO/MT direction primer** entry.

**Push (Push Notifications)**
The mobile/web push-notification lane: Orbit registers device tokens (iOS APNs, Android FCM, Huawei HMS Push Kit, Web Push VAPID) and delivers notifications to every opted-in device from the same Messaging surface, with per-device delivery results and token-decommission on abandoned endpoints. A `deep_link` field names the in-app destination a tap opens. See the [Push channel page](/channels/push).

**MO/MT direction primer (P2A / P2P / A2P)**
The direction of the hop a message travels, named from the mobile network's side. **MO (Mobile Originated)** is handset→network — a customer texting in; **MT (Mobile Terminated)** is network→handset — a business notification or a reply. The same two directions wear different names on the messaging dial: **P2A (Person-to-Application)** is always MO, **A2P (Application-to-Person)** is always MT, and **P2P (Person-to-Person)** is human-to-human traffic with no application leg — each P2P hop still travels as MO into the carrier and MT out of it. Carriers price, filter, and register the directions separately, and the receive-side asymmetry is the operational one: inbound webhooks fire only on MO routing, so when no MO route exists on a number an inbound P2A message may resolve to the tenant and still never reach your endpoint. When a reply never lands on your webhook, name the direction first, then verify the MO gate — see [Inbound message resolution](/concepts/inbound-message-resolution), the [inbound MO routing troubleshooting](/troubleshooting/inbound-sms-no-route), and the [Normalized inbound event envelope](/webhooks/normalized-inbound-envelope). The voice and messaging siblings of the same idea are **Origination / Termination** (see O); the full standalone definition lives in the **MO/MT** entry (see M).

***

## Q

**QA / Quality Management (Auto-score)**
The contact-center quality program: supervisors author weighted evaluation forms (rubric sections and criteria, plus a compliance gate), reviewers score sampled calls against them, and agents acknowledge or appeal their evaluations. **Auto-score (AI Auto-QA)** is the pipeline layer on top: an AI scorer grades eligible calls against the active scorecard, and any AI scorecard below your flag threshold queues for human review — distinct from **Sentiment Analysis** (see S), which reads a customer-emotion signal and never issues an evaluation. WFM (see W) is the neighboring but separate discipline — it plans staffing; QA measures how well staffed conversations went. Build the loop in the [Quality Management program guide](/guides/quality-management-program) and pre-flight the AI pipeline with the [AI auto-QA readiness panel](/guides/qa-autoscore-readiness-panel).

**MOS (Mean Opinion Score)**
The 1–5 voice-quality metric that compresses jitter, packet loss, and codec behavior into a single number a human panel or an algorithm assigns to a call's audio — 4.0 or higher reads as good quality, while a dip toward 3 or below means callers are hearing **Jitter** (above) or **Packet Loss** (above) damage. The [voice call quality troubleshooting](/troubleshooting/voice-call-quality) page walks the per-leg metrics behind the score, and the [Voice API](/api-reference/voice) returns MOS for recent calls. See the [full definition](https://orbit.devotel.io/glossary/mos-score).

**Quarantine**
A holding state that removes something — a sender, a delivery, an attachment, or a **CDR** (above) — from its normal rotation until a fault clears, so further traffic or billing doesn't depend on a suspect artifact. Orbit uses it in three shapes: sorting a degraded number out of the sending rotation automatically through [Closed-Loop Reputation Remediation](/numbers/health#closed-loop-reputation-remediation) until a reputation cooldown ends; a failed webhook artifact holding a delivery from replay until a decryption re-save succeeds; and the `VOICE_BILLING_CURRENCY_DEFERRED` row in [Billing pause/block recovery](/troubleshooting/billing-pause-block-recovery), where a CDR is held uncharged until currency resolution recovers instead of being dropped or mis-billed. Distinct from a **DLQ** (below), which is the permanent exhaust lane after retries burn out — a quarantined CDR or payload is meant to resume once its fault clears — and from the **Suppression list** (below), which is a tenant-owned, deliberate recipient gate, not a fault-driven hold. On inbound email, an attachment flagged malicious by the threat scan is quarantined (dropped before it reaches the AI agent) as a fault-line decision, not a suppression rule. See the [full definition](https://orbit.devotel.io/glossary/quarantine).

**Quality Rating (WhatsApp)**
Meta's per-template and per-account health signal for a WABA — **GREEN**, **YELLOW**, or **RED** — driven by recipient behaviour such as blocks and spam reports. Because it is Meta-owned rather than a tenant-owned control, a falling rating degrades how the account sends, and a maintained rating supports **Messaging Tier** (above) upgrades. When a template tips RED, Orbit surfaces `WHATSAPP_TEMPLATE_PAUSED` (Meta 132016), and when account-wide quality drops low, `WHATSAPP_ACCOUNT_QUALITY_LOW` (Meta 133000). An operator-opted-into template fires the `whatsapp.template.auto_paused` webhook when Meta reports it RED, pausing sends on it locally. See the [template troubleshooting](/troubleshooting/whatsapp-template).

**Quiet Hours**
The tenant-owned send-window control that blocks (or holds) an outbound send outside the daily window you define, per channel and per recipient-local timezone — so a campaign launched at 11pm your time doesn't land on your recipient's phone at an intrusive hour. Quiet-hours windows are **your** configuration, evaluated at send time as one gate in the outbound admission chain (alongside wallet posture, block lists, frequency caps, and throughput); the one exception is the TCPA federal voice window for US recipients, which the platform owns and cannot be over-ridden. Configure the window in the [quiet-hours guide](/guides/quiet-hours-configuration) and read how it composes in the [send-gating concept](/concepts/send-gating-and-quiet-hours).

***

## R

**Regulatory Bundle**
A reusable compliance-profile bundle of KYC documents — proof of address, business registration, and government-issued identification — that a country requires before a DID purchase can proceed past the `pending_compliance` state. A bundle is created once and reused across multiple number purchases in the same country, so you do not have to re-submit the same documents for every DID. In Orbit, the number purchase flow gates on regulatory-bundle verification: when a country requires a bundle, a purchase moves to `pending_compliance` and stays there until the bundle's documents pass review, at which point the purchase provisions automatically. The Numbers dashboard labels the bundle status as `verified` (documents approved, purchases unblock) or `pending_review` (under review, new purchases held). See [Regulatory preview](/numbers/regulatory-preview) for the per-country bundle requirements and the `pending_compliance` section of [Number lifecycle](/numbers/lifecycle) for the purchase-flow gating.

**RAG (Retrieval-Augmented Generation)**
A technique that grounds a language model's answer in retrieved content: at run time, the system searches a knowledge base for passages relevant to the current question and composes the reply from those passages instead of relying only on the model's training data. Retrieval reduces fabricated answers and lets the system cite which source it used.

**In Orbit,** RAG is the retrieval mechanism agents use against a knowledge base: each run searches the knowledge base and grounds the answer in the passages it returns. Tune it through the knowledge-pipeline settings and the knowledge base you attach to the agent. See the [knowledge-pipeline concept](/concepts/knowledge-pipeline) and the **Knowledge Base** entry.

**RTC PaaS (Real-Time Communications Platform as a Service)**
The live-media pillar — browser and in-app voice + video without carrier hand-offs: a media edge that carries speech or a video room over WebRTC and hands the agent a transcript, rather than a PSTN leg you dial out on. It serves real-time app developers on **WebRTC** (see W), **SIP** (see S), and **RTP** (below); pair with **CPaaS** (see C), which ships the asynchronous messaging APIs, and **UCaaS** (see U), which is the finished internal-calling product. Orbit ships RTC PaaS through the [voice-gateway realtime edge concept](/concepts/voice-gateway-realtime-edge) and the [video channel](/channels/video).

**RBAC (Role-Based Access Control)**
Orbit's permission system with ten roles. The five primary roles are `owner`, `admin`, `developer`, `viewer`, and `billing`. Four least-privilege seats extend it for contact-center and customer-data work: `agent` (agent console), `supervisor` (queue and call supervision), `analyst` (CDP computed-traits read), and `marketer` (campaign and data-quality). `user` is the base authenticated seat for self-service access. Each role has different API and dashboard permissions.

**RTP (Real-time Transport Protocol)**
The media-layer protocol that carries the actual audio and video packets of a call once signaling (**SIP**, above) has set the session up — the plane where **Jitter** (above) and **Packet Loss** (above) damage quality. See the [full definition](https://orbit.devotel.io/glossary/rtp).

**Ring Group**
The set of agents or extensions an inbound call dials — simultaneously or in a fixed order — before it falls through to **Voicemail** (below); one inbound queue can carry several ring groups routed by IVR menu choice. Configure inbound routing in the [Inbound number routing guide](/guides/inbound-number-routing) and the menu wiring in the [IVR visual builder](/guides/ivr-visual-builder). See the [full definition](https://orbit.devotel.io/glossary/ring-group).

**RCS (Rich Communication Services)**
The carrier-channel successor to SMS/MMS that delivers rich cards, carousels, suggested replies and action buttons, read receipts, and typing indicators inside the phone's default messaging app instead of a third-party install — the channel **Conversational Commerce** (see C) catalogs and checkouts run on alongside WhatsApp. *Orbit behavior:* you register a branded RCS agent (name, logo, color) per sending identity — the registration feeds the **Trust Score** (see T) as its `rcs_business` surface — and you send the same `/api/v1/messages` contract with an RCS-typed payload carrying card/carousel/button structure SMS cannot express. Because handset support is partial, a send through a **Cascade** (see C) falls back to SMS when the destination can't take RCS, and the shared `message_group_id` keeps the whole run one logical message. When a keyword opt-out must reach the RCS lane, register the keyword as a **Suppression list** (below) entry. See the [RCS channel page](/channels/rcs), the fallback semantics in [Cascade groups](/concepts/message-cascade-groups), and the agent-registration step in the [sender-ID registration guide](/compliance/sender-id-registration).

**RMD (Robocall Mitigation Database)**
The FCC's public registry that every US voice service provider files in before it originates calls. Under 47 CFR § 64.6305 the filing declares the provider's **STIR/SHAKEN** (below) implementation level — and, for any provider that has not fully deployed STIR/SHAKEN, a description of its robocall-mitigation program. Terminating carriers must refuse traffic from providers absent from or deficient in the database, so a missing or stale filing is a direct cause of outbound calls being blocked. Orbit tracks your filing as a **tenant-owned** lifecycle — `draft` → `submitted` → `active` → `remediation_required` → `withdrawn`, with `withdrawn` re-openable to `draft` — and you complete the FCC filing itself; an invalid transition returns `409 RMD_INVALID_TRANSITION`. See the [RMD registration guide](/compliance/rmd-registration).

**RND (Reassigned Numbers Database)**
The US database of phone numbers reported as permanently disconnected — the pre-contact check that tells you whether a number may have been reassigned to a new subscriber since you obtained consent. Orbit's read-only check endpoint `GET /api/v1/compliance/rnd/check` takes the destination number plus your `consent_date` and returns one of three verdicts: `yes` (a permanent-disconnect record post-dates the consent date — the number may be reassigned, no **Safe Harbor**, do not contact), `no` (no disconnect record post-dating consent — **Safe Harbor** applies), or `no_data` (the database holds no disconnect record — a feed-unsynced or missing verdict, no Safe Harbor asserted). The endpoint is opt-in per organization (`organizations.settings.rnd_scrub_enabled`, default OFF, returning `403 RND_SCRUB_NOT_ENABLED` while off) and its `feed_synced` flag reports whether the FCC RND snapshot (SomosGov / reassigned.us) has been ingested — until it is, every verdict fails to `no_data`. Enabling before the feed is connected is rejected as `409 RND_FEED_NOT_CONFIGURED`, so the control never pretends to screen. See the RND section in [Send gates](/compliance/send-gates#rnd).

**Retry-safety (deterministic vs transient vs conditional)**
The taxonomy behind every troubleshooting runbook's "fixes you should NOT try" section: before a retry loop, classify the error, because each class permits a different retry behavior. **Deterministic** errors — a 422 validation reject like `INVALID_PHONE_NUMBER`, or a 409 like `COMPLIANCE_PROFILE_LOCKED` — fail identically no matter how many times you resend, until the payload itself changes; never retry them. **Transient** errors — a 429 `RATE_LIMITED` or a 5xx `SERVICE_UNAVAILABLE` — succeed on retry once you honor the cooldown the envelope carries, so read `details.retry_after` before scheduling the next attempt. **Conditional** errors — a tenant-owned pre-send gate like `SENDER_ID_NOT_REGISTERED` or a locked compliance profile — fail until you fix the payload or flip the tenant-owned toggle the gate names. This splits the [From-a-code-to-a-runbook class table](/reference/error-codes#from-a-code-to-a-runbook) row by row — deterministic 422 validation, transient 429/5xx, and the tenant-owned pre-send reject gate — and each row links to its per-family runbook. Whatever class you hit, open a ticket with the envelope's `meta.request_id` — it is the durable handle on the failed request.

***

## S

**CLI / CLIP (Calling Line Identification / Presentation)**
The wire name for the caller-ID value a network presents on an inbound call — the number the callee sees before answering. CLIP (Calling Line Identification Presentation) is the supplementary service that delivers the number to the callee; the same field is called **Sender ID** on SMS. Suppressing or falsifying the presented identity crosses into **Caller ID Spoofing** (above), which **STIR/SHAKEN** (below) exists to stop. Provisioning a rotating caller-ID pool is also what the **Flashcall** OTP channel (above) requires. See [CNAM & Caller ID](/numbers/cnam) for the name-display side and **Sender ID (Alphanumeric)** below.

**Segment**
A single SMS message unit, billed separately when a message splits into more than one. The segment size depends on encoding: **GSM-7** (above) messages fit 160 characters per segment and split into 153 characters each beyond that, while a single non-GSM-7 character forces **Unicode** (below) and drops the limits to 70 characters per segment (67 for multi-part) — so one emoji or curly quote can double the segment count of the same text. Orbit reports the computed segment count per message so you can predict per-message cost before sending — see the [FAQ on segments and billing](/reference/faq).

**Sender ID (Alphanumeric Sender ID)**
The identifier a recipient sees as the source of a message or call — a **Long Code** (above), a **Short Code** (below), or, outside the US and Canada, an alphanumeric name such as `ORBIT` (up to 11 characters in most countries). An alphanumeric sender ID can't receive replies, so it suits one-way alerts and OTPs but not two-way conversations, and most countries that allow it require the name pre-registered before sending. In the US and Canada, A2P traffic instead goes through a registered 10DLC long code or short code. Sending from an unregistered or mismatched sender ID is one of the most common reasons a message gets filtered or blocked — register ahead via the [sender ID registration guide](/compliance/sender-id-registration); when an unapproved sender gates your sends, see the [pending gated surfaces troubleshooting](/compliance/troubleshooting-pending-gated-surfaces). For India-bound traffic the Sender ID registers as a **Header** under the **DLT** framework (above), recorded in the [DLT-India registry](/compliance/dlt-india). See the [full definition](https://orbit.devotel.io/glossary/sender-id) and the [alphanumeric sender ID definition](https://orbit.devotel.io/glossary/alphanumeric-sender-id).

**Session Replay**
A recorded playback of a customer's widget session — the pages they visited and the path they took — attached to the conversation for agent-side review in the inbox. See [Session replay](/concepts/session-replay).

**SSO (Single Sign-On, SAML 2.0)**
One login at your identity provider that opens the Orbit dashboard — the shipped, per-organization sign-in method an owner configures under **Settings → Security** (writes are owner-only). SAML 2.0 is the protocol beneath it: on each login your IdP sends a signed assertion, Orbit verifies it against the stored signing certificate, and a dashboard session is minted. SSO gates **dashboard login only** — API keys stay a separate credential class, and the `enforced` posture (SSO as the only method) never locks out automation. SSO decides *how* a member signs in; **SCIM** (below) decides *which users exist*. See the forwarded-assertion detail in the **SAML (Security Assertion Markup Language)** entry (below) and the model on [Identity federation: SAML and SCIM](/concepts/identity-federation-saml-scim).

**SAML (Security Assertion Markup Language)**
The XML protocol (SAML 2.0) the **SSO** entry (above) runs on: an IdP-asserted identity token Orbit verifies against your stored certificate before minting a session. The assertion flow starts one of two ways — **IdP-initiated** (the user clicks the Orbit tile on the IdP's app portal and is posted over with an assertion) or **SP-initiated** (the user opens `/auth/saml/{orgSlug}/login`, is 302-redirected to the IdP, and the IdP posts the assertion back to `/auth/saml/{orgSlug}/callback`) — and both land in the same verified session, as the [FAQ's SAML/SCIM answer](/reference/faq) lays out. Orbit publishes the metadata URL (`/auth/saml/{orgSlug}/metadata`) and ACS callback you paste into the IdP. See the [SAML enrollment guide](/guides/saml-sso-enrollment) and the [identity-federation model](/concepts/identity-federation-saml-scim).

**SCIM (System for Cross-domain Identity Management)**
The provisioning protocol (RFC 7643/7644) your IdP — Okta, Microsoft Entra ID, OneLogin, any compliant client — uses to push user and group changes into Orbit so a member exists *before* their first login, running the lifecycle **create → update → deactivate → deprovision**. The org-scoped base URL (`/scim/v2/{orgSlug}`) authenticates with a dedicated Bearer token configured under **Settings → SCIM**. SAML without SCIM still works, but without it someone invites each user manually — the two pair but never imply each other. See the lifecycle model on [Identity federation: SAML and SCIM](/concepts/identity-federation-saml-scim) and the enrollment walkthrough in the [SAML enrollment guide](/guides/saml-sso-enrollment).

**Slack**
The Slack channel routes event alerts (inbound message, voice-queue SLA warning, compliance posture changes) into a connected Slack workspace — an org admin authorizes Orbit once by OAuth, and each destination channel resolves through a tenant-owned engagement policy. The bot must be a member of the target channel or hold `chat:write.public`. See the [Slack channel page](/channels/slack).

**Sender Pool**
The pool of senders — long codes, short codes, alphanumeric sender IDs, or WhatsApp numbers — that a message draws routing from when it sends. A send walks the pool's senders in rotation and applies per-sender throughput caps and per-country eligibility, so degrading one sender moves traffic to the rest. If every sender in the pool is over its throughput limit or removed, the message rows sit against an exhausted pool until capacity returns — add senders or route through a pool with free capacity (see the [Sender Pools guide](/guides/sender-pools) and the [troubleshooting reference](/reference/troubleshooting)). Pool size should track real send volume: a pool spread thin across too many lightly-used numbers reads as **Snowshoe** (below) to carriers. See the [full definition](https://orbit.devotel.io/glossary/sender-pool).

**Sentiment Analysis**
Automated classification of a message, chat, or call transcript's emotional tone — typically positive, neutral, or negative — using natural language processing instead of a human manually tagging each interaction. Orbit's inbox surfaces a per-conversation sentiment score computed from inbound SMS, chat, email, and voice-call transcripts. See the [full definition](https://orbit.devotel.io/glossary/sentiment-analysis).

**SBC (Session Border Controller)**
The network element at a voice-network edge that polices and normalizes SIP signaling and **RTP** (above) media between two domains — security, topology hiding, and interworking — sitting between an enterprise voice system and a carrier or platform. See the [full definition](https://orbit.devotel.io/glossary/sbc).

**Softswitch**
The class-4 call-switching network element that routes and switches voice calls across carrier trunks and endpoints — the wholesale-grade engine a voice platform originates and terminates calls through, and the element Orbit deploys per tenant as the **Jambonz (SIP bridge)** (above) at the signaling edge. Distinct from a **SIP Trunk** (below), which is the connection from your PBX to a softswitch rather than the switching element itself. See the [Jambonz softswitch model](/concepts/jambonz-softswitch) and the [full definition](https://orbit.devotel.io/glossary/softswitch).

**SPF (Sender Policy Framework)**
The DNS TXT record that authorizes the mail-transfer-agent IPs allowed to send on behalf of your domain, giving receiving mail servers a positive list of permitted senders to compare the sending IP against. Orbit's daily DNS health check re-validates SPF alongside **DKIM** and **DMARC** (below), and the email dashboard reflects the current verdict with a traffic light chip per record. Drift in the SPF record — a TTL expires, a registrar edit commits, an IP pool changes — degrades sending via the daily check long before a receiver rejects on alignment; fix it on the [email DNS-drift troubleshooting](/troubleshooting/email-dns-drift) page. See the [full definition](https://orbit.devotel.io/glossary/spf).

**Short Code**
A five-or-six-digit telephone number used for high-volume application-to-person messaging, leased through a carrier-administered registry rather than assigned like an ordinary phone number. Short codes are easy for recipients to read back and support higher throughput than long codes when the use case is approved.

**In Orbit,** short codes are provisioned for high-volume messaging lanes (common in the US), and US application-to-person traffic requires prior carrier registration. The 10DLC and sender-registration guides explain how registration is filed before the short code takes traffic. See [10DLC registration](/guides/10dlc-registration).

**SLA (Service Level Agreement)**
The committed service-level target a queue or channel agrees to meet — typically "answer X% of calls within Y seconds" — that the queue SLA forecast callback webhooks watch live so an operator can re-staff before the breach lands rather than reading it in the morning report. See [SLA-breach forecast callbacks](/voice/sla-breach-forecast-callbacks) and the abandonment-rate term (above).

**Softphone**
The in-browser SIP/WebRTC phone seat an agent calls from — the contact-center calling surface where **Presence** (above) toggles, **Aux / Pause Codes** (above), and **Disposition** (below) submission happen around voice queues. It exists in three forms that share one credential path: the built-in dashboard softphone (the zero-code default), an embedded LiveKit-based component mounted inside your own agent workspace, and a SIP-over-WebSocket client registering against Orbit's WebRTC bridge. Distinguish it from the **UCaaS** (below) team softphone: the CCaaS seat is scoped to queue-dispatch and agent work — its presence toggle and reason-code pickups feed dispatch — while the UCaaS softphone is the finished internal-calling surface the [Colleagues directory](/voice/colleagues) and extensions sit on, billed per seat rather than per queue license. Setup is in the [browser softphone guide](/guides/voice-softphone-browser-calling).

**SIP (Session Initiation Protocol)**
The application-layer signaling protocol (RFC 3261) that sets up, renegotiates, and tears down a voice or video session — the INVITE/ACK/BYE handshake that negotiates a call before a single audio packet moves. SIP carries signaling only; the speech itself rides **RTP** (see R) once the session is up, which is why call-setup metrics like **PDD** (see P) live on the SIP path while quality metrics like **Jitter** and **Packet Loss** (see P) live on the RTP path. *Orbit behavior:* every PSTN leg terminates at Orbit's session border (**Jambonz**, see J), which speaks SIP on the wire and asks the platform for the per-call routing decision; your own phone system reaches the same edge over a **SIP Trunk** (below) that authenticates with SIP credentials or an IP allow-list, and the in-browser **Softphone** (above) is a SIP client carried over **WebRTC** (below) instead of bare UDP/TCP. SIP is the wire protocol a **BYOC** (see B) carrier connection speaks and the signaling counterpart of **SMPP** (below) on the SMS side — signaling, not media, just as SMPP carries the message but not the SMSC's store-and-forward. See [Voice channel capabilities](/channels/voice) for where signaling and media split in Orbit's stack.

**SIP Trunk**
The named physical/logical connection from your PBX or carrier to Orbit's voice edge — the way an on-premise or cloud phone system reaches the public telephone network over **SIP** (above) signaling and **RTP** (below) media instead of physical phone lines, so calls travel as data over one internet connection. A trunk authenticates by SIP registration (username/password) or by IP allow-listing, and carries a configurable number of concurrent call channels rather than a fixed set of physical lines. The **BYOC** pattern (above) keeps your existing carrier and numbers while Orbit handles IVR, queues, and reporting — see [Voice channel capabilities](/channels/voice) and the [SIP Trunks API section](/api-reference/voice#sip-trunks). See the [full definition](https://orbit.devotel.io/glossary/sip-trunking).

**Squad (Agent Squad)**
A tenant-scoped routing construct that composes several specialist **Agent**s (see A) behind one entry point: every inbound turn first hits the squad's **classifier** agent, which answers a single constrained question — "which of these intent labels best fits the message?" — and the resulting label decides which of the 2–6 member agents owns the turn, with an optional **fallback** catching unmatched labels and classifier failures itself. An optional daily cap (`max_cost_per_day_cents`) stops routing with a `429` once the squad's model spend hits the limit; routing loops (a classifier declared as a member, a label claimed by two members) are rejected at write time with `squad_loop_detected`. Because the classifier slot hard-owns its agent, deleting that agent is refused with `409 AGENT_REFERENCED_BY_SQUAD` until the squad is re-pointed — see [Agent errors](/troubleshooting/agent-errors). Distinct from a **Handoff** (see H) target, where one router agent hands off mid-conversation rather than a classifier labeling at the front door. Build and test squads in [Agent squads](/agents/squads).

**Snowshoe (Sender-Pool Spam)**
Spreading outbound A2P volume across many lightly-used numbers to dodge per-number carrier filters — the snowshoe analogy: each number carries only a trickle, so per-number thresholds never trip, but together they evade detection. Carriers now flag the pattern at the **Sender Pool** (above) level, so thin, oversized pools get blocked there instead of one number at a time. Orbit's deliverability autopilot watches pool shape and flags an over-spread pool for consolidation (see the [changelog](https://orbit.devotel.io/en/changelog)); pool sizing guidance is in the [SMS deliverability playbook](https://orbit.devotel.io/en/resources/sms-deliverability-playbook). See also **SMS Firewall** (below) — the carrier-side filter that catches pooled volume tricks like this one.

**Spend-Velocity Anomaly**
A compliance fraud signal that trips when spend on a tenant suddenly accelerates — bulk outbound sends to high-cost destinations, an OTP-storm on premium routes, or a burst of activity after quiet history — so the platform holds traffic for review instead of letting a stolen set of credentials drain the wallet overnight. The tenant-owned response path: rotate the leaked key, tighten destination allow-lists, and set a sane spend ceiling. See [Fraud shield](/compliance/fraud-shield) and the [full definition](https://orbit.devotel.io/glossary/spend-velocity-anomaly).

**SIM Swap**
The carrier-reported signal that the SIM behind a phone number was recently replaced — the account-takeover (ATO) red flag verification and step-up-auth flows screen on, because a fresh SIM is the end state a hijacker reaches before intercepting your SMS OTPs. **Orbit behavior:** request the `sim_swap` data package on the [Number Lookup](/numbers/lookup) endpoint (`GET /api/v1/lookup?fields=...`) and the response returns the carrier-asserted result — `last_swap_date` (the most recent SIM-change timestamp), `swapped` (whether a change falls inside the look-back window, default 240 hours), and a `risk_level` bucket (`high` within 24h, `medium` within 7d, `low` otherwise) — sourced from the GSMA Open Gateway / CAMARA SIM Swap network API. The realtime surfaces sit under `/api/v1/numbers/network-apis` — `sim-swap:check` answers the `swapped` question directly, `sim-swap:retrieve-date` returns `last_swap_date`, and `sim-swap/subscriptions` enrolls a number in continuous monitoring with CloudEvent webhook notifications on change. When no CAMARA operator is configured for the deployment, the `sim_swap` package degrades to a fail-soft `coming_soon` status rather than a fabricated verdict. Cross-check a suspect number against the **IMSI** entry (I section) to compare current-SIM against registry identity. See the [SIM Swap field on Number Lookup](/numbers/lookup) and the [full definition](https://orbit.devotel.io/glossary/sim-swap-api).

**SMS Firewall**
The carrier-side system that inspects SMS traffic in real time and blocks what resembles fraud or unauthorized routing — spam, artificial inflation of traffic (AIT), **Grey Route** (above) traffic that bypasses the carrier's commercial agreements, and **Snowshoe** (above) pool-spreading patterns. Legitimate A2P senders occasionally get caught in aggressive filtering when their route or traffic pattern resembles the abuse the firewall is tuned to catch; sending over a properly licensed, registered route (a verified 10DLC campaign or a carrier-approved aggregator) is the main way to stay clear of it. Orbit sends exclusively over licensed, carrier-approved routes. See [Network signals, fraud, and reputation](/concepts/network-signals-fraud-reputation) and the [full definition](https://orbit.devotel.io/glossary/sms-firewall).

**SMS API**
The application-layer interface a developer integrates against to send and receive SMS from code — Orbit's is `POST /api/v1/messages/sms` (see [SMS](/channels/sms)). One call handles routing, concatenation, encoding, and delivery-status webhooks, so the integrator never manages a carrier connection directly. Contrasts with **SMS Gateway** below — an SMS API is the contract a developer codes against, not the wire protocol underneath it.

**SMS Gateway**
The underlying infrastructure — historically an SMPP bind, an on-premises appliance, or a GSM-modem device — that relays SMS traffic between a sender and a carrier's SMSC. "Gateway" describes the wire-protocol connection point; most integrators never touch it directly and instead call an **SMS API** (above), which sits in front of one or more gateways.

**SMPP (Short Message Peer-to-Peer)**
The wire protocol carriers and messaging aggregators use to exchange SMS — the same protocol an SMSC expects Orbit to speak when submitting (see **SMSC**, below): an SMPP client opens a TCP or TLS session, authenticates with a `system_id`/password bind (`bind_transceiver`, or the send-only `bind_transmitter` / receive-only `bind_receiver` pair), then submits messages as `submit_sm` PDUs and receives **DLR**s (above) back over the same session. Orbit exposes a direct SMPP edge at `smpp.orbit.devotel.io` (ports 2775 plain TCP and 3550 TLS) as a drop-in alternative to the REST **SMS API** (above) for high-throughput integrations — traffic bound over SMPP flows through the same routing, delivery tracking, and compliance gates either way. See the [SMPP connection guide](/guides/smpp) — the **BYOC** arrangement (above) uses the same protocol to keep traffic on your own carrier.

**SMSC (Short Message Service Center)**
The network element inside a mobile carrier's core infrastructure that stores, forwards, and delivers SMS messages between senders and handsets, queuing a message and retrying delivery if the recipient's device is temporarily unreachable until it either succeeds or the message's validity period (commonly 24–72 hours) expires. An SMS gateway never delivers text straight to a phone — it submits each message to the destination carrier's SMSC over SMPP, and the SMSC completes (or reports the failure of) that final hop. See the [full definition](https://orbit.devotel.io/glossary/smsc).

**SMS Pumping Fraud (AIT / SMS Toll Fraud)**
Bots repeatedly triggering OTP or verification texts against an app's own login/signup form to drive up the business's messaging bill on premium-rate or fraud-controlled numbers, with the attacker collecting a cut of the termination fees. Defend against it with per-number/per-IP rate limits on OTP requests and a challenge step before the SMS sends. See the [full definition](https://orbit.devotel.io/glossary/sms-pumping-fraud).

**Safe Harbor (reassigned numbers)**
The FCC shield (47 CFR § 64.1200(m)) that protects a caller from TCPA liability when an **RND (Reassigned Numbers Database)** query (above) showed no reassignment before the call — even if the number was, in fact, reassigned. On Orbit's `GET /api/v1/compliance/rnd/check` endpoint the mapping is exact: a verdict of `status: "no"` returns `safe_harbor: true`; any other verdict (`yes` or `no_data`) returns `safe_harbor: false`. The Safe Harbor check is a **tenant-owned** pre-contact control like quiet hours or DNC scrubbing — the endpoint answers "is this still the same person who consented?", while the **DNC / DND Registry** (above) answers "has this person opted out?". See the RND section in [Send gates](/compliance/send-gates#rnd).

**Sandbox / Test Mode**
The isolated sending mode you reach with a test-prefixed **API Key** (above) — a `dv_test_sk_` secret key or a `dv_test_pk_` publishable key — instead of a live `dv_live_*` credential. In test mode a send accepts as normal but terminates at the `test_sent` status with delivery simulated rather than placed on a carrier, so you can validate integrations, webhooks, and flows without spending wallet balance or stamping carrier-side sender reputation — the same body `message.sent` with `status: "test_sent"` reaches your webhook with simulated receipts. See [Sandbox, test mode, and provisioning](/concepts/provisioning-and-test-mode) and the go-live gates in the [pre-launch checklist](/sandbox/pre-launch-checklist).

**SNA (Silent Network Authentication)**
A non-delivery **Verify** factor channel — `POST /verify/send` with `channel: "sna"` — that confirms a device's possession of a phone number without texting, calling, or emailing a code the recipient can read out to an attacker. Instead of delivering an OTP, SNA checks with the device's own mobile network operator (via the CAMARA / GSMA Open Gateway broker) that the device currently holds a live session on that number — proof-of-possession, not proof-of-knowledge. Pass a device-bound `device_token`; on a confirmed match the verification returns `status: "verified"` with no OTP to intercept. Distinct from **Flashcall** (above), which still proves possession but via a code embedded in a dropped call's caller-ID digits rather than a network-level check. See [Verify](/verify/overview) for the factor-channel split.

**SS7 (Signaling System No. 7)**
The out-of-band signaling protocol suite telephone carriers use to set up and tear down calls, route SMS, and manage roaming across the **PSTN** (above) — the network-side counterpart of **SIP** (above), which runs at the application edge. See the [full definition](https://orbit.devotel.io/glossary/ss7).

**Subaccount**
An organizational sub-unit created under a parent organization — a full organization of its own, with its own plan, API keys, users, senders, and wallet, linked to the parent by a single parent pointer (nesting stops there: a subaccount cannot parent another). Every **API Key** (above) is issued against exactly one organization, and the auth layer resolves that key to its org — parent or subaccount — on every request, so traffic, billing, and per-resource attribution stay partitioned between subaccounts. The parent funds each subaccount with credit transfers into its separate wallet and caps it with `monthly_spend_cap_cents`. See the scope chain and visibility model in the [subaccount organization model concept](/concepts/subaccount-organization-model).

**SSE (Server-Sent Events)**
A one-way HTTP streaming pattern that lets a server push events to a client over a single long-lived connection using the `text/event-stream` content type, an alternative to polling or webhooks when the client needs incremental data and the server only needs to push, not receive.

**In Orbit,** agent chat responses support SSE: set `stream: true` on the agent endpoint and the reply is delivered to the client as it is generated, token by token, rather than buffering until the full response completes. Webhooks are still used for the asynchronous completion path. See [Agents](/agents/overview) and the [webhooks concept](/concepts/webhooks).

**STIR/SHAKEN (Secure Telephone Identity Revisited / Signature-based Handling of Asserted information using toKENs)**
The US telecom framework that cryptographically signs a call's caller ID so the terminating carrier can verify where the call actually originated before it rings. Every call carries an **Attestation** level (see A, above) — Full (A) means the originating carrier authenticated the caller and confirmed their right to the calling number, Partial (B) confirms the caller only, and Gateway (C) applies to calls entering the network from an unverified source — and carriers weigh that signal alongside reputation when deciding whether to label a call "Spam Likely" or block it. Orbit tracks each outbound number's attestation tier and the answer-rate lift that tier earns over time on the Numbers page. See [STIR/SHAKEN for outbound calls](/channels/voice/stir-shaken) and the [full definition](https://orbit.devotel.io/glossary/stir-shaken).

**Sticky Sender / Sticky Routing**
The routing behavior that keeps repeat sends to the same recipient on the same sender number or carrier route, so a two-way conversation stays on one visible identity and a proven route keeps its edge until it degrades. On the sender side, the sender-resolution chain reuses the DID an existing conversation already ran on; on the carrier side, **Least-Cost Routing (LCR)** (above) gives the route that most recently delivered a sticky bonus in its per-destination ranking. See [Sender resolution](/concepts/sender-resolution), [Least-cost routing policy](/concepts/least-cost-routing), and the [full definition](https://orbit.devotel.io/glossary/sticky-sender).

**Sunset / Draining (Number and Sender Retirement)**
The lifecycle a **DID** (see D) or a **Sender Pool** (above) member passes through when it is retired: *draining* pulls the number out of the pool's routing rotation while remaining in-flight traffic on it still terminates, so ongoing conversations don't break mid-exchange — and once the last in-flight traffic clears, *sunset* (aging) marks the number fully out of service and eligible for release. The distinction matters operationally: a pool walk skips a draining number for new sends while replies to the old sends can still land, and a sunset number no longer terminates anything. See the aging states in [Number reuse & aging](/concepts/number-reuse-and-aging).

**Strict Sender / Strict Sender-ID (destination rule gate)**
An opt-in, tenant-owned toggle you set on your organization that re-checks every outbound alphanumeric **Sender ID** (above) against the destination country's format, prefix, and length rules *before* the send is submitted. **Orbit behavior:** with the toggle off (default, permissive) a violating sender is accepted and a deliverability advisory rides on the message metadata; with it on, the same send fails closed as `422 SENDER_INVALID_FOR_DESTINATION` with the offending rule in `details.rule` (`wrong_length_exact`, `restricted_prefix`, `leading_trailing_space`, `alpha_unsupported_country`) — so the reject lands in your API response instead of a carrier DLR after wallet spend. Distinct from the **DNC / DND Registry** scrub (above), which gates recipient opt-out rather than sender format. See the rule codes on the [strict sender-ID troubleshooting page](/troubleshooting/strict-sender-id-invalid-destination) and the full send-path table in [error codes](/reference/error-codes).

**STT (Speech-to-Text)**
The automatic transcription of spoken audio into text. Speech-to-text lets a voice agent treat a caller's utterance as the text input the language model can reason over before it answers — the front of the voice pipeline, paired with text-to-speech at the other end.

**In Orbit,** speech-to-text transcription runs inside the voice gateway so a caller can speak a prompt and have the agent reason over the transcribed utterance instead of forcing Dual-Tone Multi-Frequency input. It is paired with TTS, which speaks the reply back. See the **TTS** entry and [Agents](/agents/overview).

**Spam complaint rate**
The share of recipients who reported your email to their mailbox provider as spam — a recipient-clicked "report spam" feedback loop that sends a heavier penalty than a **Bounce** (above) because recipient-side negative signals land against the sender's **Sender Reputation** (below) instead of the recipient's reachability. A high complaint rate tanks sender reputation and moves traffic to the spam folder until clean sending resumes. The tenant-level sender-reputation summary endpoint returns the per-recipient complaint count alongside hard-bounce and unsubscribe rates. See the dedicated complaint-handling page in [email bounces and spam complaints](/troubleshooting/email-bounces-complaints).

**Sender Reputation**
The composite recipient-trust score a sender builds from **Bounce** + **Spam complaint rate** + engagement history — the standing a receiving mailbox provider assigns your sending domain before it accepts your mail. Distinct from the **Deliverability Score** (D section), which is predictive: the Deliverability Score estimates likelihood before a send, while sender reputation is historical — a standing the receiving provider maintains and recomputes with every signal. Orbit surfaces a tenant-level sender-reputation summary in the deliverability dashboard and the [email deliverability API](/api-reference/endpoints/email). See the [full definition](https://orbit.devotel.io/glossary/email-reputation-score) and the **Trust Score** (below) — a brand-registration-grade rollup that differs from domain-level sending reputation.

**Suppression list**
The tenant-owned set of addresses — phone numbers, email addresses, or WhatsApp IDs — that must never receive another message from your tenant, whether the recipient opted out via `STOP`, unsubscribed, bounced, complained, or landed there through a bulk CSV import. Orbit treats it as a hard send-gate: a suppressed address is dropped before dispatch regardless of how the send was triggered, until the tenant explicitly re-permits it (the re-consent path in **Opt-In / Opt-Out**, above). Manage it in [Opt-Out & Suppression Lists](/compliance/opt-out-suppression) and download the full ledger for an audit via [Export Consent & Suppression Records](/compliance/consent-suppression-export). See the [full definition](https://orbit.devotel.io/glossary/suppression-list).

**Support access (view-as)**
The tenant-owned, time-boxed door you open for Devotel support so an operator can sign in as your workspace to help with an issue. The workspace owner grants a window (15 minutes to 24 hours) under **Settings → Security → Support access**, and Devotel support can enter only while it is live. Each grant trades for a short-lived, single-use link: a reused link rejects as `TOKEN_ALREADY_USED`, a delayed or cookie-blocked browser rejects as `MISSING_COOKIE`, a revoked grant rejects as `SESSION_REVOKED`, and expired or forged links reject as `INVALID_TOKEN`. Denying access or the **End session** control on a listed session terminates it at once; every grant attempt — accepted or rejected — lands in your **Settings → Audit log** (`auth.impersonation_consumed` / `auth.impersonation_exchange_rejected` with the real reason). See the [support access troubleshooting runbook](/troubleshooting/support-access-impersonation) and the [audit log guide](/guides/audit-log).

**Supervisor Coaching Modes (listen / whisper / barge / takeover)**
The four ways a supervisor inserts themself into a live agent call, escalating from passive to full control. **Listen-in** opens a one-way audio bridge — the supervisor monitors silently and neither call leg hears them. **Whisper** puts the supervisor's voice on the agent leg only, so the caller can't hear the coaching. **Barge** joins the supervisor as a third audible participant both legs hear. **Takeover** is the warm hand-off: the supervisor absorbs the call and replaces the agent as the active party — distinct from barge, which adds a third leg, because the leg-swap drops the agent chain-side. All four require the `voice:monitor` scope; listen-in, whisper, and barge run on `POST /api/v1/voice/calls/{id}/listen`, `/whisper`, and `/barge` under the live-supervisor surface, while a failed takeover fires the `supervisor.takeover_failed` webhook when the leg-swap is declined. Don't confuse takeover with an in-call [warm transfer](/api-reference/voice#warm-transfer) — the per-call consult leg that hands the call to a *different* destination — or with a **Handoff** (above), which is AI→human escalation, not supervisor-to-agent. See the [Live supervisor API surface](/api-reference/voice#monitoring), the [agent-assist whisper coaching guide](/guides/agent-assist-whisper-coaching), and the [supervisor coaching guide](/guides/supervisor-coaching).

***

## T

**Team Chat (Huddle)**
The intra-tenant messaging surface for the people running your Orbit workspace — support agents, admins, developers — kept deliberately separate from **Live Chat** (see L): nothing posted in a team-chat channel, DM, or huddle ever reaches a customer, and no outbound customer message passes through a team-chat endpoint. Channels carry threads and read state per member, and a **huddle** is the quick voice-or-video room spawned inside a channel the moment a text thread gets too slow. Use it for the coordination that happens *around* customer work — on-call handoffs, escalation chatter — without leaving Orbit for a separate chat tool. See the [Team Chat guide](/guides/team-chat) and the [Team Chat API reference](/api-reference/team-chat).

**TCPA (Telephone Consumer Protection Act)**
The US federal statute (47 U.S.C. § 227, implemented by 47 CFR § 64.1200(c)(1)) that governs calls, texts, and faxes to US recipients — the baseline the **DNC / DND Registry** (D section) registries, **Quiet Hours** (Q section) windows, and **Consent Receipt** (C section) proof all plug into. Its best-known hard rule is the dialing window: no solicitation calls (or SMS) before 8 AM or after 9 PM **recipient-local time**. On Orbit, campaign and **Dialer** (D section) voice to US recipients is hard-blocked outside that window with `422 TCPA_FEDERAL_DIALING_WINDOW_BLOCKED` — the platform's sole fail-closed guard, with no tenant toggle — while ad-hoc 1:1 dials are advisory until you opt the `voice` channel into your own quiet-hours gate; several states layer stricter mini-TCPA windows on top. See the [TCPA posture guide](/guides/tcpa-quiet-hours-and-windows) and the [US state calling windows](/compliance/state-calling-windows).

**Throttling**
The request-admission slowdown that holds a send or API call back before it overruns a rate limit, as a backpressure response rather than a hard reject — the sender sees elevated latency or a queued state instead of a `429`, and a planned campaign slows to the allowed pace. A hard **rate-limit** reject is the opposite outcome: the request fails fast with a limit error; see [Rate limits & cooldowns](/concepts/rate-limit-and-cooldown-taxonomy) and the [rate-limits troubleshooting](/troubleshooting/rate-limits). See the [full definition](https://orbit.devotel.io/glossary/throttling).

**Telegram**
The Telegram bot messaging lane, reachable through Orbit's Telegram Bot API integration — send and receive text, media, documents, and inline keyboards. Each Orbit organization attaches one bot, and inbound updates arrive automatically on your registered webhook. See the [Telegram channel page](/channels/telegram).

**10DLC (10-Digit Long Code)**
A US carrier registration system for A2P messaging over standard 10-digit phone numbers. Registration requires a brand and campaign, both filed with **TCR (The Campaign Registry)** (below). For India-bound traffic the counterpart framework is **DLT** (above) — a per-carrier registration ledger rather than a single central registry. See the [10DLC guide](/guides/10dlc-registration).

**TCR (The Campaign Registry)**
The central clearinghouse US mobile carriers appointed to register brands and messaging campaigns for A2P 10DLC traffic. Every campaign running on US 10-digit long codes is filed with TCR — either directly or through a CPaaS partner like Orbit — and carriers look up the registration to decide the throughput and filtering that apply. See the [full definition](https://orbit.devotel.io/glossary/tcr) and the [10DLC guide](/guides/10dlc-registration).

**Tracking plan**
The tenant-owned CDP event contract: the canonical map of event names and the type of every property each event carries, which the destination catalog and the CDP event-ingest endpoint validate incoming events against — distinct from a generic schema registry, which stores payload shapes rather than enforcing an event contract. Author the plan in the dashboard under **Integrations → CDP**, where each event row declares its property names, types, enum values, required flags, and a per-event enforcement level: soft mode accepts mismatches and logs them (SDK drift stays visible without losing events), while strict mode rejects the event with `422 TRACKING_PLAN_VIOLATION` and names the rule that fired — missing required property, type mismatch, enum mismatch, or undeclared extra property. Recovery runs through the per-event violations feed at **Integrations → CDP → Tracking Plan → Violations**; the full diagnosis ladder is the [TRACKING\_PLAN\_VIOLATION runbook](/troubleshooting/tracking-plan-violations), and the plan mechanics are in the [CDP tracking plan guide](/guides/cdp-tracking-plan). Cross-links: **CDP event ingest**, **Computed trait** (see C) rules over event facts on the profile, and the **destination catalog** concept in [The reverse-ETL destination model](/concepts/reverse-etl-destination-model). See the [full definition](https://orbit.devotel.io/glossary/tracking-plan).

**Trust Score**
The 0–100 rollup on the **Brand Identity API** (`GET /api/v1/brand-identity/status`) that reads the current registration state across six surfaces — 10DLC (`messaging_10dlc`), toll-free verification, WhatsApp Business (`whatsapp_business`), RCS (`rcs_business`), branded calling (RCD / CNAM), and per-number regulatory KYC (`number_regulatory`) — and collapses them into a single score plus a prioritized `nextActions` list of what to complete next. Trust Score is cross-channel and organization-wide: it is `verified / applicable` across those six surfaces, not per-brand. Distinct from **Brand Vetting / Vetting Score** (above), which is TCR-only, per-brand, and specific to US 10DLC throughput — the trust rollup instead tells your integrations "how verified am I, everywhere." See the [Brand Identity API reference](/api-reference/brand-identity).

**Trust Registry (public lookup)**
The per-organization, opt-in public endpoint (`GET /api/v1/public/.well-known/ans/registry/lookup` with `org=<slug>` plus `agentId`, `ans`, or `phone` selectors) that answers "is this caller or agent really this brand, and what is it delegated to do?" from outside your tenant. One resolve composes three signals Orbit already computes — the **Brand Identity / Trust Score** rollup (see T's own Trust Score entry), the **STIR/SHAKEN Attestation** tier (resolved with the same logic the dial path stamps on the egress INVITE, so the registry reports the egress-time decision rather than a registry-side guess), and the delegated capability scopes of your active API keys (read through the default-deny scope ledger, with key ids, hashes, and key material never crossing the boundary). Publication is a **tenant-owned** toggle per organization: with it off, unknown organizations, opted-out organizations, and malformed lookups all collapse to the same blind `404 AGENT_TRUST_NOT_FOUND` envelope, so a probe can neither enumerate tenants nor learn who publishes; responses edge-cache for 60 seconds so a revoked agent or key drops out within a minute. Manage publication and attestation posture on the [attestation page](/compliance/attestation); the full model is in [ANS Trust Card and trust registry](/concepts/ans-trust-card-registry) and the FAQ entry in [Number identity & caller ID](/reference/faq).

**TTS (Text-to-Speech)**
Synthesizing human-sounding speech from written text. Text-to-speech lets a voice system speak a generated or templated reply to a caller without a pre-recorded human voiceover, so dynamic content can be voiced in real time — the back of the voice pipeline, paired with speech-to-text at the front.

**In Orbit,** TTS renders agent replies into spoken audio on the voice path, so a caller hears the reply instead of only reading it in a chat surface; STT handles the reverse direction. See the **STT** entry above and [Agents](/agents/overview).

**ANS (Agent Name Service) Trust Card**
The signed, verifiable caller/agent-identity anchor the emerging agent-discovery ecosystem binds an AI agent's name to — a well-known JSON Trust Card served at `/.well-known/ans/trust-card.json` under the **ANS (Agent Name Service)** draft standard, declaring the agent's `ans://v{version}.{host}` name, its endpoint surfaces, and the Ed25519 signing-key set a resolver matches against outbound signed requests. A caller ID on its own proves nothing; a published, domain-anchored, cryptographically checkable record is what fixes the "unknown-call" punishment every legitimate business caller absorbs from spoofed brands. Orbit publishes its own platform Trust Card (on `orbit.devotel.io` and the API twin `api.orbit.devotel.io`, reusing the same signing keys that already authenticate its outbound machine traffic), and the per-organization **Trust Registry** (see the Trust Registry entry above) resolves *your* tenant's posture the same way. ANS complements the NANDA AgentFacts capability sheet — ANS is the naming-and-trust layer, AgentFacts is the capability facts. The four-step verification flow and the attestation-posture levers are on [ANS Trust Card and trust registry](/concepts/ans-trust-card-registry); related anchors are **Attestation** (see A), **STIR/SHAKEN** (see S), and **Brand Identity / Trust Score** (see T).

**24-Hour Window (WhatsApp Service Window)**
The rolling customer-service window Meta opens on a WhatsApp conversation the moment a customer messages you. For 24 hours from their last inbound message you reply in free-form; after it lapses you can only reach that customer with a pre-approved **Template** (below), and the window re-opens on the customer's next inbound message. See the [24-hour window guide](/guides/whatsapp/24h-window).

**Template**
A pre-approved message format for business-initiated conversations on WhatsApp and RCS. Templates can include dynamic variables. See also: **Messaging Tier (WhatsApp Messaging Tier)** (above) and **Quality Rating (WhatsApp)** (above) — the Meta-owned mechanisms that gate template sends.

**TFV (Toll-Free Verification)**
The carrier-side verification US/Canada toll-free (8XX) senders must complete before A2P SMS or MMS leaves the platform unthrottled — Verizon, AT\&T, and T-Mobile treat unverified toll-free traffic as guaranteed-throttle: they filter it, cap it to a trickle, or drop it outright. Orbit enforces the gate as a send preflight: a US-bound send from a toll-free number whose `tfv_status` is not `approved` rejects synchronously with `422 TFV_REQUIRED`, the message never queues and never reaches a carrier, and the error body names the current status (`not_submitted`, `pending`, `rejected`) so there is nothing to guess. The filing itself is a **tenant-owned** control — one submission per number ties the sender to your business identity and use case, and a pre-submit content lint blocks a filing whose sample messages trip a disallowed-vertical pattern with `422 TFV_LINT_BLOCKED` before carrier review ever sees it. Unlike **10DLC** (above) there is no **TCR** brand-plus-campaign filing and no **Brand Vetting / Vetting Score** (see B) — one approved TFV filing covers the sender. Related identity mandates on the same tenant: the **LOA** (see L) that authorizes a number **Port** (see N), and the **Verified Caller ID** process on the voice side. Work the submission-to-approval loop on the [TFV\_REQUIRED runbook](/troubleshooting/toll-free-tfv-required) and the [FAQ entry](/reference/faq); the sibling registration frames are the [sender-ID registration guide](/compliance/sender-id-registration) and the **Trust Score** rollup (above), which reports toll-free verification as its `messaging_toll_free` surface.

**Toll-free number**
A US/Canada number that charges the recipient nothing for inbound calls or inbound texts — the cost shifts to you as the owner. The 8XX prefixes (800, 833, 844, 855, 866, 877, 888) identify these numbers across the NANP. As a number **type** — distinct from the TFV verification gate — toll-free carries a different posture than a 10DLC long code or short code: SMS on a toll-free number is send-only in Orbit's capability model (no inbound MO leg — see [country capabilities](/numbers/country-capabilities)), and before A2P SMS or MMS leaves the platform unthrottled the sender must clear the carrier-side verification filing — see **TFV (Toll-Free Verification)** (above). An unverified toll-free sender rejects the send preflight with `422 TFV_REQUIRED`; the full loop is on the [TFV runbook](/troubleshooting/toll-free-tfv-required).

**Toll-Free Verification**
The carrier-side gate a **Toll-free number** (above in this letter) must clear before US/Canada A2P SMS or MMS leaves the platform unthrottled. The filing is one submission per number tying the sender to your business identity and use case — one approved filing covers the sender, with no TCR brand-plus-campaign and no **Brand Vetting / Vetting Score** (above). This entry is the plain-language name for the acronym entry **TFV (Toll-Free Verification)** (above) — the full gate model, including the `tfv_status` states and the `422 TFV_REQUIRED` / `422 TFV_LINT_BLOCKED` preflight rejects, lives there — link there rather than repeat here.

**Tenant**
An organization or account on a multi-tenant platform: an isolated container for a group's data, users, phone numbers, and configuration. Tenancy is how one platform serves many customers while keeping each customer's data separate from every other's — the opposite of running one deployment per customer.

**In Orbit,** a tenant scopes its own users, sender numbers, agents, knowledge bases, flows, and settings, and the tenant-isolation and org/subaccount concepts describe the boundary. See [Tenant isolation](/concepts/tenant-isolation) and the [organization and subaccount model](/concepts/org-and-subaccount-model).

**Throughput**
The send-rate capacity — per second or per minute — at which a number, sender pool, or messaging service may dispatch messages before excess traffic queues, throttles, or rejects. Caps apply per number and per messaging service, enforced as the `NUMBER_MPS_EXCEEDED` and `MESSAGING_SERVICE_MPS_EXCEEDED` errors on the rate-limit taxonomy, and registration trust (a well-vetted 10DLC campaign, toll-free verification) is what unlocks a higher ceiling. Read the taxonomy in [Rate limits & cooldowns](/concepts/rate-limit-and-cooldown-taxonomy) and diagnose throttling in the [rate-limits troubleshooting](/troubleshooting/rate-limits). See the [full definition](https://orbit.devotel.io/glossary/throughput). See also: **Messaging Tier (WhatsApp Messaging Tier)** (above) and **Quality Rating (WhatsApp)** (above) — Meta's recipient-count ceiling and health signal on the WhatsApp lane.

**TOTP (Time-Based One-Time Password)**
A six- to eight-digit code generated by an authenticator app from a shared secret, as defined in RFC 6238. The app and the server both derive the same code from the secret plus the current time, typically in 30-second windows, so a code is valid only for a short interval and cannot be replayed. Enrollment happens through a provisioning URI (often shown as a QR code) that carries the secret and issuer metadata.

Unlike an **OTP (One-Time Password)** (see O) delivered over SMS, voice, or email, nothing is sent to the recipient: the authenticator app computes the code locally from the enrolled secret. This removes the carrier-delivery step and the associated line-type or inbox risks, but it also means the user must already have enrolled a TOTP factor before it can be used.

**In Orbit,** TOTP is a **Verify** factor channel, not a delivery channel. Enroll a factor with `POST /api/v1/verify/factors/totp` and verify a code with the matching factor-check endpoint. Sending `channel: "totp"` to `POST /api/v1/verify/send` is refused with `422` and points you to the factor endpoint, because TOTP is verified, not delivered. It is one factor in the Verify suite alongside **Passkey (WebAuthn)** (see P), push, SNA, backup codes, and flashcall. Passkeys are non-exportable device credentials, while TOTP secrets are portable across authenticator apps; backup codes are single-use recovery values, while TOTP codes rotate on time windows. See [Verify](/verify/overview) and the [Verify factor suite guide](/guides/verify-factor-suite).

**Tool**
A capability a virtual agent can invoke during a conversation, such as sending a message, reading a contact record, or completing a purchase. Tools extend agents beyond model-only text generation into actions on real data, and an agent chooses among its configured tools based on the conversation context.

**In Orbit,** agent tools are exposed over the Model Context Protocol (MCP) — the agent runtime calls MCP-declared tools when a conversation step needs an action. An MCP server is where those tools are defined and hosted, and the glossary distinguishes the *tool* (the individual capability) from the *server* that declares it. Agent tools are configured on the agent in the dashboard. See the [MCP hosted-server concept](/concepts/mcp-hosted-server) and [Agents](/agents/overview).

***

## U

**UCaaS (Unified Communications as a Service)**
A cloud platform that bundles a business's own internal voice, video, and team-messaging tools — browser softphone, SIP trunking, PBX replacement, find-me/follow-me — into one subscription, configured through a dashboard rather than code. Contrasts with **CPaaS** above: UCaaS is a finished internal-communications product, while CPaaS is a set of APIs a developer wires into their own application. Orbit ships both on the same tenant — its [UCaaS pillar](https://orbit.devotel.io/features/ucaas) sits alongside the core CPaaS messaging, voice, and video APIs documented here.

**Unicode**
The extended character set covering all global scripts, emoji, and special characters. In SMS, any single non-GSM-7 character puts the whole message on Unicode encoding, where **Segment**s (above) hold just 70 characters (67 for multi-part) instead of 160 — the encoding, not the visible length, decides both your segment count and what the message bills.

**USSD (Unstructured Supplementary Service Data)**
The menu-over-dial-code channel for 2G and feature phones: the subscriber dials a short code, the network opens a synchronous session, and each screen is one request/response round trip answered with a `CON ` (continue) or `END ` (terminate) disposition. Orbit models the menu as a tree of screened nodes and answers each step as a pure function of the accumulated input, so no per-session state lives anywhere. See the [USSD channel page](/channels/ussd) and the [session-model concept](/concepts/ussd-session-model).

***

## V

**VoIP (Voice over Internet Protocol)**
Voice carried as data packets over IP networks instead of the circuit-switched **PSTN** (below) — the transport model the entire **SIP** (above) + **RTP** (above) stack runs on. SIP is VoIP's signaling protocol and RTP its media protocol; PSTN is what a VoIP call interconnects with when it terminates off-net. See the [full definition](https://orbit.devotel.io/glossary/voip).

**vCon (Virtual Conversation)**
The IETF-standardized signed container format for an entire conversation — all parties, the transcript, recordings, and analysis — that survives export and import intact, proven via its digital signature. Orbit ships conversation export and import as signed vCon containers; see [Export conversations as signed IETF vCon containers](/guides/conversation-export-vcon) and the container placement in the [export families model](/concepts/export-families-model).

**Validity Period**
The per-message time-to-live — how long the sending pipeline tries to deliver before stopping and closing the message as `expired`. On the carrier side the **SMSC** (above) stores and retries an SMS until it either succeeds or the message's validity period runs out; on the Orbit send itself the terminal row decodes as `expired` (time-to-live exceeded before send — resend with a longer window or fix the hold that stalled it). A **Messaging Service** (above) binds a default `validity_period` for every message sent through it via the sender-resolution chain, so you set the policy once on the service rather than per send. See the per-message settings on the [sender-resolution concept](/concepts/sender-resolution) and the `expired` row of the status decoder in the [troubleshooting reference](/reference/troubleshooting).

**Codec (Voice Codec)**
The encoder/decoder pair that compresses a voice waveform into the packets an **RTP** (see R) stream carries and back — trading audio fidelity against bandwidth and handling at call setup: **OPUS** is the wideband, high-fidelity pick that sounds clearer at lower bitrate, **G.711 µ-law (PCMU)** is the uncompressed, toll-quality narrowband codec US/Canada PSTN trunks default to, and **G.711 A-law (PCMA)** is its twin on the rest of the world's trunks. Orbit supports all three and negotiates **OPUS → PCMU → PCMA** in that preference order at call setup, per leg; when endpoints can't agree, the call connects with no usable media (see the [voice call quality troubleshooting](/troubleshooting/voice-call-quality) page's codec-mismatch check). Manage the channel surface in [Voice channel capabilities](/channels/voice). See the [full definition](https://orbit.devotel.io/glossary/voice-codec).

**Verify**
The Orbit product pillar dedicated to one-time-password (OTP) verification: it manages a code's lifecycle over the send and the check endpoints, keeps sessions, and applies anti-replay and throttling rules. Verify speaks across SMS, WhatsApp, voice, flashcall (SNA), and email, and a sandbox `test_sent` mode returns a predictable response without consuming a real factor channel during integration testing.

**In Orbit,** a verification session is created with the send endpoint, the user's entered code goes to the check endpoint, and the product enforces the configured attempt maximum and resend cooldown. Choose a factor channel per session — SMS, WhatsApp, voice call, flashcall (SNA), or email. See [Verify](/verify/overview) and the [verification lifecycle](/concepts/verification-lifecycle).

**Voice Biometrics**
The inbound-call speaker-recognition check that scores whether the caller's voice matches the profile your tenant enrolled — flagging an impostor before an agent discloses account details, as a tenant-owned control. See [Voice biometrics](/concepts/voice-biometrics).

**Voicemail**
The mailbox that records a caller's message when no one answers — on Orbit, a tenant-owned core voice feature: per-box greeting, message storage, and transcription, configured in [Voicemail boxes](/guides/voice-voicemail-boxes); the same pickup case **AMD** (above) detects on outbound dialing.

***

## W

**WFM (Workforce Management)**
The planning discipline that turns predicted contact volume into schedules: a **forecast** projects how much work arrives (per channel, per 30-minute interval, over the next seven days), **staffing** converts each interval's volume into the required agent count via Erlang-C against your service-level target, and shrinkage and intraday adherence then account for the agents who are scheduled but absent or off-task in the moment. Distinct from **QA / Quality Management** (see Q), which evaluates how well conversations went after the fact — WFM plans who is on the floor, QA scores what those conversations contained; the broader workforce-optimization (WFO) umbrella covers both. Orbit ships WFM as a per-tenant surface — forecasts, staffing optimizer, intraday adherence, shift requests — all interval-grained to match the ACD. See the [Forecasts and staffing optimizer guide](/guides/wfm-forecasts-and-staffing-optimizer) and the [WFM API reference](/api-reference/wfm).

**Wallet Passes (Apple / Google Wallet)**
Digital passes — loyalty cards, coupons, event tickets — that you issue through the Orbit Wallet Passes API or the dashboard issuance builder and that customers save to their phone's wallet app. The state machine, generation counter, and responsibility ledger are tenant-owned; delivery is just a `save link` you send in any message, SMS, WhatsApp, or email. See the [Wallet Passes channel page](/channels/wallet-passes) and the [wallet pass lifecycle concept](/concepts/wallet-pass-lifecycle).

**WeChat (Official Account)**
China's super-app messaging channel: Orbit wraps the WeChat Official Account template-message API so you deliver pre-approved template messages to your OpenID followers from the same unified Messaging surface. Official Account tokens gate sends; inbound follows (joins) and unfollows are verified on the webhook route but not dispatched. See the [WeChat channel page](/channels/wechat).

**WebRTC (Web Real-Time Communication)**
The open browser and mobile stack that carries real-time audio and video without plugins — the capture, transport, and NAT-traversal machinery behind the video channel and the browser **Softphone** (above). Orbit's media SFU sits on WebRTC for in-browser voice and video, registered through its WebRTC bridge — see [Media planes](/concepts/media-planes), the [Video channel](/channels/video), and the [browser softphone guide](/guides/voice-softphone-browser-calling), plus the [full definition](https://orbit.devotel.io/glossary/webrtc).

**WebSockets**
The persistent bidirectional transport that keeps a live-data session open between a browser and a server — the channel that delivers **Live Chat** (below) messages and the dashboard's real-time inbox without polling. When the transport is the suspect, see the [cobrowse-stuck troubleshooting](/troubleshooting/cobrowse-stuck); the [full definition](https://orbit.devotel.io/glossary/websockets).

**WABA (WhatsApp Business Account)**
The registered business identity on Meta's WhatsApp Business Platform that owns a company's WhatsApp phone numbers, message templates, and messaging permissions. Approval runs through Meta Business verification, then display-name and template review; Orbit's WhatsApp onboarding walks you through it end to end. See the [full definition](https://orbit.devotel.io/glossary/waba) and the [WABA setup guide](/guides/whatsapp/waba-setup).

**Wallboard (Supervisor Wallboard)**
The real-time supervisor display of live queue health — calls waiting, **Service Level** against the queue's **SLA** target, longest wait, agents available — built to run on a shared screen (a TV on the ops floor) for floor-wide situational awareness without opening a reporting tool. Orbit ships two surfaces: the **voice wallboard** at `/voice/wallboard` with per-queue live figures, SLA-warning banners, and the top-performers leaderboard, and the **cross-channel wallboard** at `/wallboard` fusing message-level tiles with a live voice-operations band — with caller numbers masked by default for shared displays. Supervisor-scoped by role; narrower than an analytics dashboard — glanceable live state, not historical drill-down. See the [Wallboard guide](/guides/wallboard) and the [full definition](https://orbit.devotel.io/glossary/wallboard).

**Warm Transfer / Consultative Transfer**
An in-call transfer that hands a live conversation to a different destination through a consult step: the calling agent places the original caller on hold and dials a third leg, gets a private whisper window with the answering party, then completes the handoff so the two legs connect. Unlike **Supervisor Coaching**'s *takeover* (S section), which switches a supervisor into the agent's own queue-side leg on the same call, a warm transfer routes the call to a *different* destination — an external number or another queue. Drive the consult over `POST /api/v1/voice/calls/{id}/warm-transfer`, then `/warm-transfer/complete` or `/warm-transfer/cancel` (see the [warm-transfer endpoints](/api-reference/voice#warm-transfer)); a failed or cancelled consult returns `409 TRANSFER_FAILED`, distinct from the supervisor-side `supervisor.takeover_failed` webhook.

**Webhook**
An HTTP callback Orbit sends to a URL your application owns whenever something happens — a message is delivered, a call ends, a reply arrives. Instead of polling an API for changes, your server exposes an HTTPS endpoint and Orbit POSTs the event to it as it occurs, signed with HMAC-SHA256 (`X-Orbit-Signature`) so your code can verify it before acting. Acknowledge deliveries quickly and process them asynchronously — a slow or failing endpoint can stall retries and drop events past the retry window. See the [full definition](https://orbit.devotel.io/glossary/webhook) and the [Webhook Security guide](/webhooks/security).

**Warmup (Number and Sender Registration)**
Gradually ramping message or call volume on a newly registered sender — a fresh **Long Code**, **Short Code**, alphanumeric **Sender ID**, or 10DLC-registered number (all above) — instead of sending at full volume from day one, since carriers have no delivery history to judge a brand-new sender by and treat a sudden burst as spam-like, flagging or filtering it before registration fully proves out. This is the non-email counterpart of **IP Warmup** (above), which ramps email sending IPs and domains: same reputation principle, applied to messaging and voice senders — start with low volume to engaged recipients after registration completes and increase it over days as deliverability holds.

**Wrap-up / ACW (After-Call Work)**
The post-call work window between the conversation ending and the agent returning to available — the slice of **AHT** (above) beyond talk and hold, and the `wrapup` **Presence** (above) state dispatch keeps the agent off the eligible list during. Orbit runs the window per queue (the queue's wrap-up seconds setting): it ends when the timer expires or the agent submits a **Disposition** (below) early, and a queue with disposition-required set holds the agent's `busy → available` flip until one is recorded. Configure the outcome catalog in [Wrap-up codes](/voice/wrap-up-codes) and read how the state gates routing in the [agent presence lifecycle concept](/concepts/agent-presence-lifecycle).

***

## Z

**Zalo (Vietnam messaging)**
Vietnam's leading messaging app, wired through Orbit's Zalo Notification Service (ZNS) — a **beta** channel where onboard takes provisioning a Zalo Official Account and a ZNS access token; then OTP, transactional, and marketing templates deliver from the unified Messaging surface. See the [Zalo channel page](/channels/zalo).

***

## CDP terms

**Decisioning / Next-Best Action (multi-armed bandit)**
The ranker that picks the next-best message variant, channel, and send-time for one contact profile. Each request evaluates one profile against N candidate **arms**, an arm being one variant × channel × optional send-hour combination carried with its observed `trials` and `successes` counts, and returns them scored and ranked rather than merely counted: the output is the policy's pick plus the full per-factor breakdown — posterior mean, policy score, chosen/explored flags — so the decision can be explained rather than baldly read. Because counts arrive per request, the same counts always return the same pick under the deterministic policies (`bayes_ucb`, `ucb1`), and the model picks the arm most likely to convert *this* profile rather than a fleet-wide winner; eligibility gates (a per-arm switch, a channel allowlist, a resolved profile's opt-outs and exhausted frequency-cap slots, a target send hour) hold arms out of selection while keeping them in the scored breakdown. Decisioning **decides only — it never sends**: the chosen variant is rendered and dispatched by the caller, through your tenant's own consent, frequency-cap, and quiet-hours controls. It sits on top of two other profile signals in this glossary: the **Computed trait** (below), a deterministic server-evaluated rule stamp, and **Predictive-model scores** (below), the `churn_propensity` / `conversion_intent` classification models — decisioning consumes both as ranking inputs, and the `engagement_fatigue` score is a natural arm-level input: an arm on a channel the profile is tiring of gets suppressed from selection, so the bandit steers each profile away from the channel burning them out. Decide interactively in the **Audience → Decisioning** tester or programmatically at `POST /api/v1/cdp/decisioning/decide`; the full model is in [Next-best-action decisioning](/concepts/decisioning).

**Decisioning terminology (glossary anchors)**

* **Multi-armed bandit** — the decision policy family: it balances exploiting the current best arm against exploring under-sampled ones, so traffic shifts toward the leader automatically as counts accumulate, unlike a fixed [A/B test](/guides/campaign-ab-testing) assignment.
* **Arm / Variant** — one candidate action: a message variant on a channel at an optional send-time, with the trials and conversions you have observed for it.
* **Next-best action** — the ranked pick the policy returns for this profile; the sibling engines rank next-best **product** ([recommendations](/concepts/recommendations)) and next-best **channel**.

**Computed trait**
A new fact a deterministic rule stamps onto a contact's profile: you author a predicate over contact facts — lifetime value, last seen, lifecycle stage, opt-in flags — and every matching contact carries the rule's `output_tag` as an attribute, which then behaves like any other attribute (segmentable, personalizable, exportable). The rules are server-maintained rather than re-run on read: a scheduled job re-evaluates them and the dashboard preview-evaluates them inline. Author and operate rules in the [Computed traits guide](/guides/computed-traits); the model-scored sibling of these rule-based traits is **Predictive-model scores** (below).

**Reverse ETL**
The export direction of a warehouse integration — where plain ETL pulls rows *into* a warehouse, reverse ETL ships the CDP's contacts, computed traits, and segments *out* to a destination system (a warehouse table or an external endpoint). Orbit's reverse-ETL family covers both directions on the integrations page: **sources** that pull warehouse rows into the CDP event stream, and **destinations** that export profile and audience rows out — with per-destination run-status (`failing` / `stale` / `never_run`) classifying each downstream. Operate both families in the [CDP reverse-ETL and warehouse exports walkthrough](/guides/reverse-etl-warehouse-exports) and the operator page in [CDP reverse ETL and data share](/guides/cdp-reverse-etl-and-warehouse-exports); the destination-catalog verdicts are in [The reverse-ETL destination model](/concepts/reverse-etl-destination-model).

**Identity graph / Device graph**
The two views the CDP's identity-resolution pipeline (see **CDPaaS** under C) gives an operator into how identifiers stitched into one profile: the **identity graph** answers "which identifiers ended up on this resolved profile?" — emails, phone numbers, and persistent user IDs folded into one record with merge provenance — while the **device graph** answers "which anonymous sessions are the same not-yet-identified visitor?" by surfacing shared device and cookie signals across pre-identify sessions. Both views depend on the identity-rules editor that sets stitching priorities. See [Identity graph and device graph](/concepts/cdp-identity-graph-and-device-graph) and the resolution pipeline in [identity resolution and merge semantics](/concepts/cdp-identity-resolution).

**Clean room**
A two-party analytics surface that answers *how much of your audience is also ours?* without either side exposing raw contact rows: each party's identifiers are hashed before comparison, the join returns only counts and rates, and every number is withheld when the overlap is small enough to single out a person (k-anonymity suppression). Orbit's clean room sits inside the CDP and treats the hashing contract and the suppression threshold as tenant-owned controls you confirm before sharing. See [CDP clean rooms](/concepts/cdp-clean-room-model) for the full model and the operator walkthrough.

**Predictive-model scores (churn propensity / conversion intent / lifetime value / engagement fatigue)**
The four built-in predictive-model keys the CDP scores profiles on, named in API requests and returned in endpoint responses: `churn_propensity` and `conversion_intent` are classification models returning a probability (P(an active contact churns); P(an open lead converts)), `lifetime_value` is the one regression model returning a predicted value in cents (and feeding the canonical `vip` / `high` / `medium` / `low` value tiers), and `engagement_fatigue` is a classification model returning the probability a subscribed contact opts out or disengages. Each model echoes its `kind` (`classification` or `regression`) and `output_unit` (`probability` or `value in cents`) in the catalog response. Train, score, drift-monitor, and activate them in the [CDP predictive models guide](/guides/cdp-predictive-models).

**Identity Resolution (CDP)**
The deterministic-plus-probabilistic pipeline that folds each incoming identifier — normalized email, E.164 phone, stable `external_id`, and the SDK-minted `anonymous_id` — onto one contact profile, with precedence rules set per tenant per identifier type and survivorship decided by per-request pins, the tenant survivorship policy, then the blank-safe default. Auto-merges clear an operator-set threshold; the fuzzy remainder ranks into a steward review queue; every fold writes a `merge_id`, a 30-minute undo window, and an audit row with the verdict and corroborating identifiers. The **Identity graph / Device graph** (above) are the operator views over this pipeline. Full semantics in [identity resolution and merge semantics](/concepts/cdp-identity-resolution) and [identity graph and device graph](/concepts/cdp-identity-graph-and-device-graph).

**Cohort (CDP)**
A frozen membership snapshot carved from a live audience — used where a re-refreshing segment would drift: click-cohort retargeting (contacts who clicked a tracked link, attributed at generation) and incrementality measurement (treated vs. control cohorts in lift reports). Membership never re-evaluates; a later window means a fresh cohort. See [audience autosuggest and cohort export](/concepts/audience-autosuggest-and-cohort-export) and [cdp ad-audience incrementality](/concepts/cdp-ad-audience-incrementality).

**Frequency Cap (send admission)**
The tenant-owned rolling-window rule the CDP decisioning layer consults when ranking arms — a profile whose channel slots are exhausted suppresses that arm — and that every outbound send enforces atomically before dispatch: one per-cap sorted-set counter per recipient, a single atomic check-and-claim round-trip, and synchronous denial (`FREQUENCY_CAP_EXCEEDED` for API sends, `frequency_capped` for campaigns). Category scoping keeps a marketing cap from counting service traffic. Model in [frequency caps](/concepts/frequency-caps-model); endpoints and recipes in the [frequency caps guide](/guides/frequency-caps).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.