Platform runtime map
Orbit ships as a small set of separately deployable services, each with one job. This page names every one of them, tells you what it owns, and points you to the concept page that covers it in depth. If you are orienting yourself in the platform for the first time, read this page once and then follow only the deep dives relevant to your work. Customer- and tenant-facing traffic reaches exactly two request paths: the API and the web dashboard. Everything else on this page is either a worker fleet, a realtime edge, an AI runtime, or an internal operator surface.1. The request path
Two services handle everything synchronous and user-facing:- API. Every REST call, every webhook receiver endpoint, every authenticated tenant read or write enters here. The API resolves the tenant, validates the request, enqueues durable work, and answers synchronously when it can. Webhook registration targets, API keys, and page-level status all resolve to this service. See Transport architecture for the request transport model and Tenant isolation for how the API binds a request to exactly one tenant schema.
- Dashboard and mobile surfaces. The web dashboard is the operator UI for every tenant-facing feature: numbers, messaging, billing, campaigns, AI agents, inbox, analytics. A mobile app mirrors the same subscriber surface for end users. Neither surface mutates data directly — everything goes through the API.
2. The async backbone
Work that must outlive a request, run on a schedule, or retry beyond the initial call is enqueued by the API and consumed by a dedicated worker service.- Webhook worker. The worker fleet behind all durable background work — scheduled sweeps, reconciliation passes, contact imports, retry follow-ups, webhook fan-out, and every other deferrable job on the platform. See Async processing model for the producer/consumer split and the queue registry, Scheduler fleet for how the ~250 scheduled workers are grouped and guarded, and Webhook fan-out & event sinks for the outbound delivery model.
3. Realtime voice and messaging edges
These services sit at the carrier edge, where traffic meets the network in realtime:- Voice gateway. The realtime SIP/media edge for AI voice and media-streaming calls. It terminates SIP legs, runs speech-to-text and text-to-speech across provider chains, and hands the session to an agent. See Voice gateway realtime edge and Media planes.
- SMPP reconciler. Reconciles delivery receipts (DLRs) arriving over SMPP against the messages your tenant sent, so a final status lands on the right message even when receipts arrive out of order. See SMPP edge model and DLR: two planes.
- SIPREC uploader. Streams call recordings off the SIPREC forwarder and into durable storage, then attaches them to the call record. See Recording lifecycle and Call recording pipeline.
- MO bridge. Resolves mobile-originated (inbound) SMS against your tenants and routes each message to the correct conversation or webhook. See Inbound message resolution.
- Voice biometrics. Verifies a caller’s voiceprint against the enrolled samples and reports a pass/fail verdict back to the voice layer. See Voice biometrics.
4. AI and agent runtime
The agentic surfaces run on two services that keep LLM work off the request path:- Agent runtime. Executes AI agents — chat, voice, SMS, and email — orchestrating tool calls, model hops, and run state. See AI agent architecture and Agent run lifecycle.
- MCP server. Exposes the platform’s hosted MCP surface so external agents and tooling call Orbit capabilities through a typed tool surface. See MCP hosted server.
5. Internal and operator surfaces
Two operator-facing applications complete the runtime; tenants never hit either one:- Admin console. The internal administrative UI for platform-level operations, tenant posture, queue health, and global controls. See Operator observability map and Admin tenant plane.
- Mission control. The fleet operations dashboard that watches service health, scheduler runs, and queue backlogs across the runtime. Same altitude as the observability map above — nothing here leaks into tenant-visible behavior.
Service-to-concept map
What this page is not
- Not a deployment topology. This page does not describe regions, availability zones, replicas, network paths, or hosting claims — nothing here is an uptime or placement statement.
- Not a dependency contract. Service names and ownership boundaries are stable; the individual choices each service makes (which provider, which queue, which store) belong on the linked concept page and can change underneath this map.
- Not an exhaustive checkpoint of every schedule. The ~250 scheduled workers the webhook worker runs are enumerated in that service’s own concept pages, not here.