Tables & Orders

The endpoints below are the foundation of every POS integration with Mozrest. They cover the two resources Mozrest needs to mirror reservations into your POS: the tables Mozrest matches RMS reservations against, and the orders Mozrest opens when guests arrive.

Tables

Mozrest needs to know which tables exist in your POS so it can match them with the tables configured on the RMS side. This is the single endpoint required.

Get Tables

Retrieve the list of tables for a venue. Mozrest uses this to match POS tables with RMS reservations.

GET /venue/{venueId}/tables
Authorization: Bearer {api_key}

Response

[
  { "id": "T12", "name": "Table 12" },
  { "id": "T15", "name": "Table 15" }
]

Field	Type	Description
id	String	Unique table identifier in the POS
name	String	Human-readable table label

---

Orders

When a guest arrives at the venue, Mozrest opens an order in your POS. From that point on, your POS owns the order lifecycle and exposes endpoints so Mozrest can read the current state and reconcile billing later.

Create Order

When a guest is seated, Mozrest creates an order in the POS. Orders are only opened when the guest has arrived — the date field represents the seating/arrival time, expressed in UTC (see Dates and timezones).

POST /venue/{venueId}/orders
Authorization: Bearer {api_key}
Content-Type: application/json

Payload

Field	Type	Required	Description
id	String	No	Mozrest internal order ID. Can be stored for reconciliation purposes.
tables	Array	Yes	POS table IDs (e.g. ["T12"] or ["T12","T13"] for merged tables)
guestName	String	No	Guest name
guestEmail	String	No	Guest email
guestTelephone	String	No	Guest phone
partySize	Integer	No	Party size
prepayment	Number	No	Prepaid amount. Always sent; 0 when the booking carries no prepayment.
date	String	No	Seating time in UTC, format Y-m-d H:i:s with no offset and no Z (e.g. 2026-10-15 09:45:00). If omitted, treat as current time.
items	Array	No	Pre-ordered items the guest selected through the RMS. See Pre-ordered items below. Omit the field entirely when there are no pre-orders.
employeeName	String	No	Name of the employee in charge of the reservation in the RMS (e.g. the assigned server). Plain name only, no employee number. Sent only when the RMS provides it.

tableId (string) is deprecated — use tables instead.

note

date is UTC

date is the seating time in UTC. A booking at 13:45 in Dubai (UTC+4) is sent as 2026-10-15 09:45:00. The POS must convert this value to the venue's local timezone before comparing it with the current time or opening the order. Use the venue's timezone setting, not a fixed offset.

Pre-ordered items

Recommended capability

Supporting pre-ordered items is recommended but not mandatory. Most reservation system partners are now asking for pre-orders to flow into the POS at seating, so building support unlocks more integration scenarios for your venues. Implementations that do not yet support pre-orders should accept the request and ignore the items field — Mozrest does not require item handling for the order to be considered created.

When the RMS gives Mozrest a pre-order alongside the reservation (e.g. fixed menu, pre-paid courses, drinks pack), Mozrest forwards each item as { sku, quantity, notes? }:

Field	Type	Required	Description
sku	String	Yes	Product code as known to your POS. Must match a SKU configured for the venue.
quantity	Integer	Yes	Strictly positive integer.
notes	String	No	Free-text note from the guest (e.g. allergens, "no ice").

POS partners that support pre-orders should add each resolved item to the order/open check on creation. If a SKU is unknown to your POS, return 422 with a body listing the offending SKUs ({ "error": "Unknown SKU(s)", "unknownSkus": ["WINE-012"] }) so Mozrest can surface the problem back to the RMS.

Example

{
  "id": "fd30c18b-71fb-43f7-b895-34ab0b9ceced",
  "tables": ["T12"],
  "guestName": "John Doe",
  "guestEmail": "john.doe@mail.com",
  "guestTelephone": "34646883377",
  "partySize": 4,
  "prepayment": 50.00,
  "date": "2025-02-15 14:30:00"
}

Example with pre-ordered items

{
  "tables": ["T12"],
  "guestName": "John Doe",
  "partySize": 2,
  "date": "2025-02-15 14:30:00",
  "items": [
    { "sku": "PIZZA-001", "quantity": 2 },
    { "sku": "WINE-012", "quantity": 1, "notes": "no ice" }
  ]
}

Response

{
  "id": "98765",
  "checkNumber": "232323233"
}

---

List Orders

Return orders for a venue, optionally filtered by status and time window.

GET /venue/{venueId}/orders
Authorization: Bearer {api_key}

Query parameters

Parameter	Type	Description
status	String	Filter: open or closed. If omitted, return all.
from	String	Start of time window, ISO 8601 in UTC with Z suffix (e.g. 2025-02-01T00:00:00Z)
until	String	End of time window, ISO 8601 in UTC with Z suffix (e.g. 2025-02-28T23:59:59Z)

Response

Each order must include: id, status, tables, partySize, guestName, checks (array), and timestamps (createdAt, updatedAt, closedAt). Timestamps are ISO 8601 in UTC with Z suffix (e.g. 2025-02-15T14:30:00Z); closedAt is null while the order is open.

Each check must include: checkNumber, status, totalAmount, tax, tip, discount, paymentMethod, and items.

totalAmount is the sum of the check's line items — tax, tip and discount are reported separately, and the settled amount is derived as totalAmount + tax + tip − discount (see Payment details).

[
  {
    "id": "62ebe5e7210c83a0f3adf9d1",
    "status": "open",
    "tables": ["T12"],
    "partySize": 2,
    "guestName": "John Doe",
    "createdAt": "2025-02-15T14:30:00Z",
    "updatedAt": "2025-02-15T15:00:00Z",
    "closedAt": null,
    "checks": [
      {
        "checkNumber": "98765",
        "status": "open",
        "totalAmount": 150.00,
        "tax": 12.00,
        "tip": 20.00,
        "discount": 10.00,
        "paymentMethod": "card",
        "items": [
          { "id": 1, "name": "Steak", "price": 40.00, "quantity": 2 },
          { "id": 2, "name": "Wine", "price": 70.00, "quantity": 1 }
        ]
      }
    ]
  }
]

---

Get Order by ID

Retrieve a single order with all its checks.

GET /venue/{venueId}/orders/{orderId}
Authorization: Bearer {api_key}

The response uses the same structure as a single item in the List Orders response.

---

Closed Orders Retention

Closed orders must remain accessible via GET for 45 days after closure. This allows for reconciliation and billing cycle alignment. After 45 days, you may archive or remove them per your own policy.