Robotics Open Serving
Sitora Robotics Open Serving lets restaurant owners serve food with robots —
their own hardware or a contracted third-party fleet — through a public,
versioned API. This section is the vendor-facing contract; the
machine-readable half is the OpenAPI document served live at
GET /api/robotics/v1/openapi.json (no authentication required) and rendered
in the API reference pages of this site.
The model: Sitora describes work, never motion
Section titled “The model: Sitora describes work, never motion”Sitora is the workflow authority, not a fleet manager. When a paid order reaches a physical handoff state, Sitora offers a serving task to the filial’s activated fleet. Your controller claims it (first claim wins), drives the robot, and reports constrained progress. There are no motion primitives — navigation, obstacle handling, and physical safety are entirely yours, under the certified robotics contract.
Two legs exist:
| Leg | Trigger | Completes into |
|---|---|---|
dine_in_tray |
order becomes ready (confirmed dining spot) |
served |
delivery_courier |
order becomes out_for_delivery |
delivered |
Takeout has no robot leg: the receiving party is the customer, not an attesting staff member.
Completion proposes the order transition; it never executes it directly.
The filial’s confirmation policy decides: human_confirmed (default — staff
confirm the serve) or auto_confirm (the backend applies the transition
after your completed report, which must come at least the configured dwell
after arrived).
Failure is always safe
Section titled “Failure is always safe”Every failure mode — an expired offer, a robot fault, an offline fleet, a pause, a platform freeze, or staff simply serving the order first — degrades silently to the unchanged human workflow. A robot can delay nothing and block nothing; the worst outcome of any robotics failure is that a human serves the order, exactly as they would have without robots.
Eligibility: three layers, all required
Section titled “Eligibility: three layers, all required”A filial can receive offers only when all of the following hold:
- Vendor certified — your fleet passed the conformance suite and Sitora certified you.
- Plan entitlement — the restaurant’s subscription plan includes the robotics feature.
- Activation active — the filial’s robotics activation was requested by the owner, approved in Sitora Console, and is not paused.
On top of those, offers stop while the platform freeze is engaged or while
the fleet’s heartbeat is stale. The current
state of every layer is visible in the fleet snapshot’s blocked_reasons.
Data you will and will not see
Section titled “Data you will and will not see”The task manifest carries the order display number, item names and quantities, and the destination (dining spot label/number, or the delivery address for courier legs). You will never receive customer identity, contact numbers, or payment data. Do not ask for them.