> ## Documentation Index > Fetch the complete documentation index at: https://docs.orbit.devotel.io/llms.txt > Use this file to discover all available pages before exploring further. # Platform runtime map > The deployable services that make up Devotel Orbit — what each one owns, what it produces and consumes, and which concept page covers it in depth. # 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](/concepts/transport-architecture) for the request transport model and [Tenant isolation](/concepts/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](/concepts/async-processing-model) for the producer/consumer split and the queue registry, [Scheduler fleet](/concepts/scheduler-fleet-model) for how the \~250 scheduled workers are grouped and guarded, and [Webhook fan-out & event sinks](/concepts/webhook-fan-out-and-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](/concepts/voice-gateway-realtime-edge) and [Media planes](/concepts/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](/concepts/smpp-edge-model) and [DLR: two planes](/concepts/dlr-model-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](/concepts/recording-lifecycle) and [Call recording pipeline](/concepts/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](/concepts/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](/concepts/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](/concepts/ai-agent-architecture) and [Agent run lifecycle](/concepts/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](/concepts/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](/concepts/operator-observability-map) and [Admin tenant plane](/concepts/admin-tenant-plane-model). * **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 | Service | Its job | Deep dive | | ---------------------- | -------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | API | Resolve tenant, enqueue work, answer synchronously | [Transport architecture](/concepts/transport-architecture), [Tenant isolation](/concepts/tenant-isolation) | | Web dashboard / mobile | Operator UI and subscriber surface | [Overview](/concepts/overview) | | Webhook worker | Scheduled sweeps, retries, webhook fan-out | [Async processing](/concepts/async-processing-model), [Scheduler fleet](/concepts/scheduler-fleet-model), [Webhook fan-out](/concepts/webhook-fan-out-and-event-sinks) | | Voice gateway | SIP/media edge for AI and streamed calls | [Voice gateway edge](/concepts/voice-gateway-realtime-edge), [Media planes](/concepts/media-planes) | | SMPP reconciler | Match SMPP DLRs back to sent messages | [SMPP edge](/concepts/smpp-edge-model), [DLR: two planes](/concepts/dlr-model-two-planes) | | SIPREC uploader | Move SIPREC recordings into durable storage | [Recording lifecycle](/concepts/recording-lifecycle) | | MO bridge | Resolve inbound mobile-originated SMS | [Inbound message resolution](/concepts/inbound-message-resolution) | | Voice biometrics | Voiceprint enrolment and verification verdict | [Voice biometrics](/concepts/voice-biometrics) | | Agent runtime | Execute AI agents across channels | [AI agent architecture](/concepts/ai-agent-architecture), [Run lifecycle](/concepts/agent-run-lifecycle) | | MCP server | Hosted MCP tool surface | [MCP hosted server](/concepts/mcp-hosted-server) | | Admin console | Internal platform operations UI | [Operator observability](/concepts/operator-observability-map) | | Mission control | Fleet health and scheduler oversight | [Operator observability](/concepts/operator-observability-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. When you reach for a specific behavior — a queue, a voice edge, an agent run, a scheduler family — start from the concept page this map hands you to, not from this page.