> ## Documentation Index > Fetch the complete documentation index at: https://docs.tryoto.com/llms.txt > Use this file to discover all available pages before exploring further. # Platform architecture > How the OTO platform fits together: its four surfaces, how data enters and leaves, what stays separate, where it runs, and how you can extend it. This page is the shape of the platform as you will meet it: what the pieces are, where data enters and leaves, and what stays separate from what. It is written for people evaluating OTO or building against it, rather than as an internal engineering diagram. ## Four surfaces, one platform Everything runs on the same data. What differs is who is looking at it and on what device. | Surface | Who uses it | For | | - | - | - | | **The dashboard** | Operations, customer service, finance, administrators | Orders, shipments, inventory, rules, settings — the whole platform. | | **OTO PACK** | Warehouse and shop staff, on a handheld | Picking, packing, dispatch and receiving, against bins and barcodes. See [Warehouse Management](https://docs.tryoto.com/modules/warehouse-management/overview.md). | | **OTO FLEX** | Your own drivers, on a phone | Routes, pickups, deliveries and proof of delivery. See [OTO FLEX](https://docs.tryoto.com/modules/oto-flex/overview.md). | | **Public pages** | Your customers | Tracking, returns and address verification — on your domain and your branding. See [Branded pages](https://docs.tryoto.com/modules/customer-notification/branded-pages.md). | Beneath all four sits the same [REST API](https://docs.tryoto.com/developers/overview.md). The dashboard is not privileged: what it does, your own systems can do. ## How data enters and leaves | Direction | Route | | - | - | | **In** | **Sales channels** — orders synced in real time from connected storefronts and marketplaces. | | | **The API** — orders, products and stock pushed by your own systems. | | | **The dashboard** — manual order entry and bulk upload. | | | **Scanning** — barcodes at receiving, picking, packing and delivery. | | **Out** | **Carriers** — shipment bookings, with tracking events coming back. | | | **Messaging providers** — SMS, email and WhatsApp on your own accounts. See [Messaging providers](https://docs.tryoto.com/integrations/messaging-providers.md). | | | **Sales channels** — stock levels, statuses and tracking links written back. | | | **Webhooks** — events pushed to your systems as they happen. See [Webhooks](https://docs.tryoto.com/integrations/webhooks.md). | ## The order is the spine Architecturally, the thing that makes the rest coherent is that an order is **one record from checkout to doorstep**. Shipments, boxes, picks, messages, returns and charges all attach to it rather than living in systems of their own. > [!TIP] > > **This is why questions have single answers** > > Routing can weigh distance against stock because it sees both on the same record. A tracking page shows one normalized status across four carriers because the statuses land on one order. A return matches its original sale because it never stopped being the same order. > > Every one of those is trivial with a shared record and genuinely hard without one — which is the architectural argument for one operations platform rather than a set of connected tools. ## What is separated from what One account can contain a lot. These are the boundaries that matter. | Boundary | What it separates | | - | - | | **Account** | Your business. The outer boundary — nothing crosses it. | | **Brand** | Trading identities within one account: logo, sender name, message templates, tracking page. See [Core concepts](https://docs.tryoto.com/get-started/core-concepts.md). | | **Hub** | Stock, staff, bins, picking method and working hours, per location. See [Hubs Management](https://docs.tryoto.com/modules/hubs-management/overview.md). | | **User scope** | Which hubs a person can work in, and which screens and actions they can reach. See [Users, roles & permissions](https://docs.tryoto.com/platform/users-roles-and-permissions.md). | | **Sub-account** | For marketplace operators: each seller is a separate account under a master. See [Marketplaces](https://docs.tryoto.com/integrations/marketplaces.md). | ## Where it runs | | | | - | - | | **Hosting** | Managed public cloud infrastructure. There is nothing to install and nothing to patch. | | **Data residency** | A deployment decision. **In-Kingdom hosting is available** for merchants who require Saudi data to remain in Saudi Arabia. See [Security & compliance](https://docs.tryoto.com/platform/security-and-compliance.md). | | **At the edge** | A web application firewall sits in front of the platform. | | **Certification** | ISO 27001 and SOC 2 Type II, both 2026. | ## Environments | Environment | Base URL | What it is | | - | - | - | | **Production** | `https://api.tryoto.com` | Real orders, real carriers, real invoices. | | **Sandbox** | `https://staging-api.tryoto.com` | Same paths and payloads, with test carriers. Its own account and its own token. | > [!WARNING] > > **The cutover is the risk, not the build** > > Sandbox and production differ in the things integrations tend to hard-code: carrier contracts, hub codes, brand names, credentials. > > Keep every environment-specific value in configuration from the first commit. A value typed into a request during development is the classic first-day-live incident, and it is entirely avoidable. ## Where the platform can be extended | Extension point | What it lets you change | | - | - | | **Rules** | How orders are routed and carriers chosen, without code. See [Order routing](https://docs.tryoto.com/modules/omnichannel-oms/order-routing.md) and [Shipping automation](https://docs.tryoto.com/modules/shipping-management/shipping-automation.md). | | **The API** | Anything the dashboard does, done by your systems instead. | | **Webhooks** | Your systems reacting to what happens, without polling. | | **Custom connectors** | A connector OTO builds against endpoints you expose, for a system with no ready-made integration. See [ERP systems](https://docs.tryoto.com/integrations/erp-systems.md). | ## Designing an integration that behaves Three properties of the system are worth knowing before you build against it. | | | | - | - | | **Events can repeat** | A webhook may be delivered more than once. Make reprocessing harmless rather than assuming exactly-once. | | **Events can arrive out of order** | Network timing does not respect your state machine. Never move an order backwards because an older event arrived late. | | **Channels are eventually consistent** | Stock and status take a moment to reach a sales channel. A figure that differs for a few seconds is the system working, not failing. | The practical detail — retry strategy, token refresh, signature verification — is in [Errors & rate limits](https://docs.tryoto.com/developers/errors-and-rate-limits.md) and [Webhook events](https://docs.tryoto.com/developers/webhook-events.md). ## Where to go next > **[Core concepts](https://docs.tryoto.com/get-started/core-concepts.md)** > > The vocabulary these pieces use. > **[Developers](https://docs.tryoto.com/developers/overview.md)** > > The API underneath all of it. > **[Security & compliance](https://docs.tryoto.com/platform/security-and-compliance.md)** > > Certification, residency and controls. ## Related topics - [Platform announcements](https://docs.tryoto.com/platform/announcements.md) - [Ecommerce operations platform and shipping gateway](https://docs.tryoto.com/index.md) - [Sales channel integrations](https://docs.tryoto.com/integrations/sales-channels.md) This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.