Endpoints the POS Must Expose
These endpoints must be implemented by the POS system so Mozrest can retrieve table data and manage orders.
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 |
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.
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 |
date | String | No | Seating time (Y-m-d H:i:s). 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. |
tableId(string) is deprecated — usetablesinstead.
Pre-ordered items
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, e.g. 2025-02-01T00:00:00Z) |
until | String | End of time window |
Response
Each order must include: id, status, tables, partySize, guestName, checks (array), and timestamps (createdAt, updatedAt, closedAt).
Each check must include: checkNumber, status, totalAmount, tax, tip, discount, paymentMethod, and items.
[
{
"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.