API Basics

Authentication

All API requests must include a Bearer token in the Authorization header.

Authorization: Bearer {api_key}

• Only HTTPS requests are accepted.
• Your API key will be provided by Mozrest during onboarding.

Dates and timezones

All dates and times exchanged with Mozrest are in UTC. Mozrest never sends venue local time, and no value must be read as local time. Converting to the venue's local time is the responsibility of the POS: use the venue's timezone setting in your system, not a fixed offset, so daylight saving changes are handled correctly.

Two formats are used:

Format	Example	Fields
Y-m-d H:i:s, UTC, no offset and no Z	2026-10-15 09:45:00	date on Create Order
ISO 8601, UTC, Z suffix	2026-10-15T09:45:00Z	from and until on List Orders; createdAt, updatedAt and closedAt on order responses

Example: a booking at 13:45 in Dubai (UTC+4) is sent as 2026-10-15 09:45:00.

Errors

Mozrest uses standard HTTP response codes.

Code	State	Description
400	Bad Request	Invalid or missing required parameters
401	Unauthorized	API key is missing or incorrect
403	Forbidden	Valid request but insufficient permissions
404	Not Found	The requested resource does not exist
409	Conflict	Request conflicts with current state (e.g. table already occupied)
500	Server Error	Unexpected server-side error
503	Unavailable	Temporary server overload or maintenance

Error response format

{
  "error": {
    "code": 400,
    "message": "Validation failed",
    "details": {
      "checks": [
        { "checkNumber": ["This value should not be blank."] }
      ]
    }
  }
}

Best practices

• Validate request payloads before submission.
• Implement retries with exponential backoff for 500 and 503 errors.
• Log and monitor all 4xx and 5xx errors.

Forward Compatibility

Mozrest may add new fields to request and 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.

Definitions

Payment details

Payment information sent from the POS should include:

Field	Type	Description
totalAmount	Number	Sum of the check's line items (subtotal). Excludes tax and tip, before discount is deducted.
tax	Number	Tax applied to the bill
tip	Number	Gratuity added by the guest
discount	Number	Any applied discounts
paymentMethod	String	Payment method: card, cash, etc.

Mozrest derives the settled bill amount as totalAmount + tax + tip − discount. Line-item prices are tax- and discount-exclusive, so the sum of a check's items equals its totalAmount.

Split tender

paymentMethod is an informational label — Mozrest does not reconcile per tender. If a bill is split into separate checks in the POS, report multiple checks, each with its own paymentMethod. If a single check is settled with more than one payment method, keep it as one check and report a single label (recommended: split). Do not create artificial checks to represent tenders.

Order and check statuses

Status	Applies to	Meaning
open	Order / Check	Active and in progress
closed	Order / Check	Completed and paid
void	Check	Cancelled / voided