What the RMS Must Provide

Your RMS must expose two things for the POS integration to work:

1. A webhook endpoint to receive POS order events from Mozrest.
2. A table listing endpoint so Mozrest can match POS tables to RMS reservations.

Integrations that use check matching require two additional endpoints — a reservation listing endpoint and a walk-in creation endpoint.

---

Webhook Endpoint

Mozrest sends a POST request to your endpoint whenever a POS order is created, updated, or voided — and when the POS reports that an order could not be opened (see Error events).

• Method: POST
• Content-Type: application/json
• Authentication: Bearer token in the Authorization header

Authorization: Bearer {api_key}
Content-Type: application/json

Payload

{
  "type": "create",
  "venueId": "your-venue-id",
  "bookingId": "your-booking-id",
  "checkNumber": "98766",
  "partySize": 2,
  "date": 1719599400,
  "status": "OPEN",
  "tables": [
    "28c3ce8b-8c10-4a64-8099-f0dffcc549a8"
  ],
  "openedAt": 1535548784,
  "updatedAt": 1535548784,
  "closedAt": null,
  "voidedAt": null,
  "commercials": {
    "totalAmount": 150.00,
    "tax": 12.00,
    "tip": 20.00,
    "discount": 10.00,
    "prepayment": 0,
    "paymentType": "credit_card"
  },
  "items": [
    { "id": 1, "name": "Steak", "price": 40.00, "quantity": 2 },
    { "id": 2, "name": "Wine", "price": 70.00, "quantity": 1 }
  ]
}

Event types

type value	When it fires
create	The first event for an order — a new order is opened in the POS
update	Any subsequent change (items, payment, close, void)
error	The POS reported that the order could not be opened (e.g. table already occupied). See Error events

There is no separate event type for closed or voided orders: they arrive as update events — check the status field (CLOSE, VOID) and the closedAt / voidedAt timestamps.

Core fields

Field	Type	Description
type	String	Event type: create or update
venueId	String	Your venue identifier (RMS-side ID, not a Mozrest ID)
bookingId	String	Your booking identifier (RMS-side ID). May be null on creation if no reservation is linked yet
checkNumber	String	Check/order identifier in the POS
partySize	Integer	Number of guests
date	Integer	Order timestamp (UTC Unix)
status	String	OPEN, CLOSE, or VOID
tables[]	Array	Table IDs associated with the order

Timestamps

Field	Type	Description
openedAt	Integer	When the order was opened (UTC Unix)
updatedAt	Integer	Last update timestamp
closedAt	Integer	When closed (nullable)
voidedAt	Integer	When voided (nullable)

Commercials

Field	Type	Description
commercials.totalAmount	Number	Final amount after tax, tip, and discounts
commercials.tax	Number	Tax applied
commercials.tip	Number	Gratuity
commercials.discount	Number	Discounts applied
commercials.prepayment	Number	Amount already prepaid
commercials.paymentType	String	credit_card, cash, check, or others

Items

Field	Type	Description
items[].id	Integer	Item ID in the POS
items[].name	String	Item name
items[].price	Number	Price per unit
items[].quantity	Integer	Quantity ordered

Webhook retries use exponential backoff if your endpoint fails to respond with a 2xx status.

Error events

Some POS systems process order creation asynchronously: Mozrest's acceptance of your reservation webhook does not guarantee the order opened on the POS. When the POS later reports a failure, Mozrest forwards it to your endpoint as a type: "error" event so you can surface it to the venue:

{
  "type": "error",
  "venueId": "your-venue-id",
  "bookingId": "your-booking-id",
  "checkNumber": null,
  "tables": [
    "28c3ce8b-8c10-4a64-8099-f0dffcc549a8"
  ],
  "errorCode": "TABLE_OCCUPIED",
  "errorMessage": "Table already occupied",
  "occurredAt": 1719599400
}

Field	Type	Description
type	String	Always error
venueId	String	Your venue identifier (RMS-side ID)
bookingId	String	Your booking identifier — use it to correlate the failure with the reservation you sent
checkNumber	String	Check/order identifier in the POS, when one exists. Usually null — the order never opened
tables[]	Array	Table IDs associated with the attempted order
errorCode	String	Error code as reported by the POS (nullable; values vary per POS)
errorMessage	String	Human-readable reason as reported by the POS
occurredAt	Integer	When Mozrest received the failure (UTC Unix)

errorCode and errorMessage are relayed verbatim from the POS — treat them as display/diagnostic text rather than a fixed enumeration.

Retrying after an error

After receiving an error event, you can re-send the reservation webhook with the same bookingId (see Sending Reservation Events to the POS). Mozrest treats it as a fresh attempt and re-pushes the order to the POS — there is no need to create a new reservation.

---

Table Listing Endpoint

Mozrest calls this endpoint to retrieve your venue's table list. This is used during onboarding and for ongoing table matching with POS systems.

• Method: GET
• Path: /venue/{venueId}/tables
• Authentication: Bearer token

Response

[
  {
    "id": "28c3ce8b-8c10-4a64-8099-f0dffcc549a8",
    "name": "001"
  },
  {
    "id": "00f8c6da-3967-4e56-98b9-5ee063b05292",
    "name": "002",
    "posId": "POS-002",
    "area": "Terrace",
    "areaId": "AREA-1"
  }
]

Field	Type	Required	Description
id	String	Yes	Unique table identifier in the RMS
name	String	Yes	Human-readable table label
posId	String	No	POS-side table identifier. When provided, Mozrest uses it to verify table matching. Mismatches are flagged for manual review.
area	String	No	Name of the area/room the table belongs to. Matched case-insensitively against existing areas; a new area is created when no match is found.
areaId	String	No	Your area identifier. When provided, it takes precedence over area for matching.