Getting started
Read this once before integrating. It covers the two environments, how authentication works, and the identifiers used throughout the API.
Environments
| Env | Base URL | Notes |
|---|---|---|
| Sandbox | https://api-sandbox.mozrest.com | What partners integrate against during onboarding. |
| Production | https://api.mozrest.com | After sandbox sign-off, Mozrest provisions production credentials separately. |
Authentication
Mozrest provisions a fixed, non-expiring bearer token per partner. There is no token refresh, rotation, or short-lived credential flow — the same token is valid until Mozrest explicitly revokes it. Pass it on every request:
Authorization: Bearer <token>
The token is partner-wide, not per-venue. All venues in your scope are accessible with the same token. If a token is compromised, contact support@mozrest.com to revoke and reissue.
A request to a venue outside the token's scope returns 403 Forbidden.
Identifiers at a glance
| Field in this doc | What it is | Where you get it |
|---|---|---|
venueId | Mozrest's canonical venue identifier (24-char hex, Mongo-style) | GET /v1/pos/partner/venues — call this once at onboarding to learn your venue scope |
orderId | A Mozrest order (one seating; UUID) | The id field returned inside each order in the list-orders response |
externalId | POS-side order identifier — useful for reconciling with POS-side reports | Returned inside each order |
venueId and orderId are Mozrest IDsThey are stable and canonical regardless of which POS sits behind the venue. tableId and the externalId inside each order are POS-native — useful for reconciling with POS-side reports, but they can change if a venue switches POS or the venue renames a table.
Read-only
Every endpoint in this API is GET. The Analytics API never writes to a POS or to Mozrest's databases — it surfaces data Mozrest already holds, captured from the live integration with the venue's POS.
Forward compatibility
Mozrest may add new fields to response payloads at any time. These additions are not considered breaking changes.
Your integration must:
- Ignore unknown fields — do not reject or fail when receiving properties that are not in your current implementation.
- Use lenient deserialization — avoid strict schema validation that would break on new fields.
Mozrest will never make backward-incompatible changes (removing fields, changing types, or altering semantics of existing fields) without prior notice and a migration plan.