Skip to content
Sitora Docs

APIs and authentication

Sitora runs four API families on one backend. They share the same schema discipline and the same principle — workflow truth is computed server-side — but each has its own principal type, and two of them are public.

First-party app API

Section titled “First-party app API”

Used by the Sitora, Sitora Pro, and Sitora Biz apps. These contracts ship inside the apps and are not published for external integration — they can change with any app release.

Console API

Section titled “Console API”

Used by Sitora Console, the internal administration surface. Reserved for Sitora staff. Not published.

Robotics API — public

Section titled “Robotics API — public”

/api/robotics/v1/ is the surface certified robot fleet controllers integrate against directly. It is URL-versioned, additive within v1, and fully documented in the Robotics API section.

  • Auth: Authorization: Bearer sit_rk_<key> — a filial-scoped robot credential issued by the restaurant owner. The credential is a machine principal: it is not a user, has no membership, and can never act in staff workflows.
  • Discovery: the machine-readable contract is served live, without authentication, at GET /api/robotics/v1/openapi.json. The API reference section of this site is generated from that same document.

Payment Device API — public

Section titled “Payment Device API — public”

/api/payments/v1/ is the surface enrolled payment devices integrate against: smart POS companions and customer-facing displays. It is URL-versioned on the same terms as the robotics surface and fully documented in the Payment Device API section.

  • Auth: Authorization: Bearer sit_pd_<key> — a device credential claimed once with a one-time enrollment code the restaurant owner issues. Like a robot credential it is a machine principal, and the filial and station behind it are derived from the key rather than sent by the caller.
  • Discovery: the machine-readable contract is served live, without authentication, at GET /api/payments/v1/openapi.json, and the API reference pages of that section are generated from it.

The two public surfaces are separate contracts with separate credentials. A robot credential is refused everywhere on the payment surface, and a device credential is refused everywhere on the robotics surface.