ملاحظة اللغة
عند عدم توفر ترجمة، يظهر المحتوى الإنجليزي أدناه كخيار بديل. حافظ على رموز الأخطاء ومسارات 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, firesqueue.sla_breach_forecast before callers bail — see SLA-breach forecast callbacks and the callback documentation in 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 concept and the Voice queues guide.
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.
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 and of 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.
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.
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.
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) 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? 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.
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.
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; 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 and the catalogs in Hold and pause 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.
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; the tier math is in the 10DLC registration guide and the SMS channel page. 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 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 adetails.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 and the rate-limit troubleshooting guide.
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, the launch-time gate in HIPAA_BAA_REQUIRED, and the compliance page in BAA posture.
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 checklist. See the custom domains and managed SSL concepts and the branding console white-label guide.
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 page and the suppression model in Opt-Out & Suppression Lists.
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 itstarget_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) and the porting endpoints.
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.
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 concept page, the voice call park troubleshooting page, and 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.
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 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.
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, and see the identity surfaces in 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 and the billing impact in the pricing & throughput guide.
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 and the incrementality holdout model.
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 and Inbox.
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.
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.
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; walk the specific failure shapes on the consent-receipt-invalid troubleshooting page.
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). 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) and the dashboard walkthrough in BYOK: register, activate, rotate, and revoke.
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).
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 and the survey events in the webhook reference.
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.
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.
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 and the assembly guide in Assemble your tenant’s compliance posture.
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.
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.
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.
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.
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.
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.
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, 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 for the pillar split and the 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, the 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 and the Branding console and white-label guide on the white-label feature page.
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 and the Analytics pipeline concept.
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 and the dashboard-side Track a cascade guide. 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) 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, the identity-resolution and merge semantics concept, and the CDP API.
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. See the full definition.
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.
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.
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 callsPOST /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), which let a supervisor listen silently, whisper, barge, or take over an active call after an alert. See the Agent distress alert model and 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 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.
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, the send-time gate triage in voice destination blocks, and the error code in the Error Code Reference.
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; trace the failure shapes on the consent-receipt-invalid troubleshooting page.
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. 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 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, the erasure endpoint details in the Contacts API, and the cancel-or-wait recovery on the pending-compliance and erasure gates troubleshooting page.
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; 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 covers the cancel-or-wait recovery. Confirm jurisdiction handling with counsel — the DSAR guide 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.
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); decode the per-row statuses behind it on the status-by-row reference.
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. See Numbers overview and how routing resolves a DID in Sender & Routing; the per-number endpoints are in the Numbers API.
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, 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.
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 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 and the Dialer API.
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, Call disposition tags, and the outbound-dialer variant in 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); 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 and the webhook deliveries, retries, DLQ, and replay 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. The full status vocabulary a DLR drives is the Message Status Lifecycle (see M) entry. See the full definition.
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 and the row-by-status decoder in the troubleshooting reference; the per-message route step itself is defined in 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 and 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 page and the email channel guide.
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 and the FAQ entry in the Voice 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, the Provision and operate eSIM / IoT SIMs lifecycle guide, and the reseller sibling in eSIM reseller billing model.
F
Frequency Cap The tenant-owned send-admission rule that bound-checks each recipient’s rolling send count — “no more thanmax_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; the counter and gate-order model is in the frequency-cap model concept, 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 and the FAQ entry in the Voice 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.
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 and SIP-trunk connection troubleshooting.
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 and the Fax send workflow guide.
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.
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 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 that walks the per-stage timeline and the porting endpoints.
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. 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. 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. 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 and the conversation-level pause semantics in Agent run lifecycle. See the full definition. 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; the error-code playbook lives in Troubleshooting: Orby pending-action approval; and the operator-side workflow is Using Orby in the dashboard. See the full definition.
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.
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.
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 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 and the enablement runbook in HIPAA enable blocked until the BAA is 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 router and the operator runbook in Ring groups end to end.
I
Idempotency / Idempotency-Key The deduplication contract Orbit applies toPOST 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, the wallet-side collision errors in Idempotency and billing gates, and the error-code taxonomy in the Error Code Reference.
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.
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.
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 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 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 and Video channel capabilities.
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 DIDs so every inbound call executes your menu instead of a carrier’s. The low-code build surface is the IVR visual builder guide and the add-speech-understanding model is IVR routing with 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. Also see Identity Resolution (below) for the CDP function that folds incoming identifiers onto one profile, and the full definition.
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 and the operator flow in the Identity resolution guide.
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 and the lifecycle guide.
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 and the lifecycle guide.
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.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 and Agents. 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. 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 (the other is a funded balance): until a review landsapproved, 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.
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, and the throughput caps on the chosen path are separate (Throughput, above). Preview the ranked routes with the dry-runGET /api/v1/messaging/lcr/route-quote and manage the policy with the GET / PUT /api/v1/messaging/lcr/policy endpoints under the Messaging API; the scoring inputs and configuration patterns are in Least-cost routing policy.
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.
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 for the stage detail and the porting endpoints.
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.
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.
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. 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.
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 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). See the full definition. MCCMNC The concatenated MCC+MNC record key that billing and pricing use when referring to one destination operator — a single string like26201 (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, Billing API — mccmnc-overrides).
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.
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 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.
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; 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 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 and the sister message-queued triage; the transition rules the lane entry respects are on the 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 and the enqueued-empty-states checklist. 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. 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). 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, the per-status semantics on the delivery lifecycle, and the full definition.
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, the Messaging Services API, and the sender chain concept.
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 page and the VERIFY_EMAIL_UNDELIVERABLE failure shape in 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 — 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 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 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.
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 and the inbound MO routing troubleshooting, plus the full definition. 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) 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, and see the channel surface in the MMS channel page, the segment mechanics it skips in SMS segments & encoding, and the full definition.
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 and the client setup walkthroughs in the MCP server handshake guide.
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 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.
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.
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 and the six-state status map, plus the porting practice in Number portability model and the purchase-to-release flow in 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 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.
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.
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 — and when a call lands on a TURN relay path, the video call quality troubleshooting 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 alongside CSAT (above) and delivered via survey.response webhooks in the webhook reference.
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 and the end-to-end masking sessions guide.
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.
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, the cascade semantics in Cascade failover policy, and the FAQ entry in the 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 thetarget_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, the ownership model in the number-port-out model concept, 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 and the per-direction capability matrix in 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 and the 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, record and audit consent directly through consent management, and read the full mechanics — including bulk CSV import and the re-consent path — in Opt-Out & Suppression Lists. See also the MessageSuppression API 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: 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. Confirmed grants land in the same consent ledger every other surface reads — see the 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.
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, the operator workflow in Using Orby in the dashboard, and the endpoint contract in the Orby API reference.
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 with422 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 and the compliance posture in BAA posture.
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 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 and the full definition.
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.
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 apply symmetrically when you’re on the losing side, and the per-rejection recovery runbook is Troubleshoot port-out rejections.
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.
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.
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.
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.
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 for setup and the degraded-state decoder 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 and 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.
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, the inbound MO routing troubleshooting, and the Normalized inbound event 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 and pre-flight the AI pipeline with the AI auto-QA 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 page walks the per-leg metrics behind the score, and the Voice API returns MOS for recent calls. See the full definition. 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 until a reputation cooldown ends; a failed webhook artifact holding a delivery from replay until a decryption re-save succeeds; and theVOICE_BILLING_CURRENCY_DEFERRED row in 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.
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.
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 and read how it composes in the send-gating concept.
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 thepending_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 for the per-country bundle requirements and the pending_compliance section of Number 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 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 and the video channel.
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.
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 and the menu wiring in the IVR visual builder. See the full definition.
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, the fallback semantics in Cascade groups, and the agent-registration step in the sender-ID registration guide.
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.
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.
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 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 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. 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 asORBIT (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; when an unapproved sender gates your sends, see the pending gated surfaces troubleshooting. For India-bound traffic the Sender ID registers as a Header under the DLT framework (above), recorded in the DLT-India registry. See the full definition and the alphanumeric sender ID definition.
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.
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.
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 lays out. Orbit publishes the metadata URL (/auth/saml/{orgSlug}/metadata) and ACS callback you paste into the IdP. See the SAML enrollment guide and the identity-federation model.
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 and the enrollment walkthrough in the SAML enrollment guide.
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.
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 and the troubleshooting reference). 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.
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.
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.
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 and the full definition.
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 page. See the full definition.
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.
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 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 and extensions sit on, billed per seat rather than per queue license. Setup is in the browser softphone guide.
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 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 and the SIP Trunks API section. See the full definition.
Squad (Agent Squad)
A tenant-scoped routing construct that composes several specialist Agents (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. 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.
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); pool sizing guidance is in the 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 and the full definition.
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 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 and the full definition.
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 and the full definition.
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). 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 DLRs (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 — 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.
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.
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.
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 and the go-live gates in the 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 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.
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.
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 and the webhooks concept.
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 and the full definition.
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, Least-cost routing policy, and the full definition.
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.
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 and the full send-path table in 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.
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.
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. See the full definition 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 and download the full ledger for an audit via Export Consent & Suppression Records. See the full definition.
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 and the audit log guide.
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 — 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, the agent-assist whisper coaching guide, and the supervisor coaching guide.
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 and the Team Chat API reference. 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 with422 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 and the US 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 and the rate-limits troubleshooting. See the full definition.
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.
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.
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 and the 10DLC guide.
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, and the plan mechanics are in the CDP tracking plan guide. 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. See the full definition.
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.
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; the full model is in ANS Trust Card and trust registry and the FAQ entry in Number identity & caller ID.
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.
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; 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.
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 and the FAQ entry; the sibling registration frames are the sender-ID registration guide 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), 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.
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 and the organization 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 and diagnose throttling in the rate-limits troubleshooting. See the full definition. 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 and the Verify factor suite guide.
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 and Agents.
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 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 Segments (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 aCON (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 and the session-model concept.
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. 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 and the container placement in the 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 asexpired. 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 and the expired row of the status decoder in the troubleshooting reference.
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 page’s codec-mismatch check). Manage the channel surface in Voice channel capabilities. See the full definition.
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 and the 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.
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; 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 and the WFM API reference. 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 asave link you send in any message, SMS, WhatsApp, or email. See the Wallet Passes channel page and the wallet pass lifecycle concept.
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.
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, the Video channel, and the browser softphone guide, plus the full definition.
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; the full definition.
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 and the WABA setup guide.
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 and the full definition.
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); 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 and the Webhook Security guide.
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 and read how the state gates routing in the agent presence lifecycle concept.
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.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 observedtrials 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.
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 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) and next-best channel.
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; 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 and the operator page in CDP reverse ETL and data share; the destination-catalog verdicts are in The 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 and the resolution pipeline in identity resolution and merge semantics.
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 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.
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 and 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 and 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; endpoints and recipes in the frequency caps guide.