Platform architecture

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.
OTO FLEX	Your own drivers, on a phone	Routes, pickups, deliveries and proof of delivery. See OTO FLEX.
Public pages	Your customers	Tracking, returns and address verification — on your domain and your branding. See Branded pages.

Beneath all four sits the same REST API. 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.
	Sales channels — stock levels, statuses and tracking links written back.
	Webhooks — events pushed to your systems as they happen. See Webhooks.

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.

This is why questions have single answersRouting 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.
Hub	Stock, staff, bins, picking method and working hours, per location. See Hubs Management.
User scope	Which hubs a person can work in, and which screens and actions they can reach. See Users, roles & permissions.
Sub-account	For marketplace operators: each seller is a separate account under a master. See Marketplaces.

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.
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.

The cutover is the risk, not the buildSandbox 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 and Shipping automation.
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.

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 and Webhook events.

Where to go next

Core concepts

The vocabulary these pieces use.

Developers

The API underneath all of it.

Security & compliance

Certification, residency and controls.

Get started

Modules

Integrations

Developers

Platform

Pricing

Platform architecture

Four surfaces, one platform

How data enters and leaves

The order is the spine

What is separated from what

Where it runs

Environments

Where the platform can be extended

Designing an integration that behaves

Where to go next

Core concepts

Developers

Security & compliance

​Four surfaces, one platform

​How data enters and leaves

​The order is the spine

​What is separated from what

​Where it runs

​Environments

​Where the platform can be extended

​Designing an integration that behaves

​Where to go next

Core concepts

Developers

Security & compliance

Four surfaces, one platform

How data enters and leaves

The order is the spine

What is separated from what

Where it runs

Environments

Where the platform can be extended

Designing an integration that behaves

Where to go next