Check Matching

Mozrest can link POS checks to your reservations — automatically or through the Mozrest check-matching tool — and create walk-in bookings in your RMS for checks that have no reservation.

This capability is optional. The base POS integration (order events + table listing) works without it. To enable check matching, your RMS must expose two additional endpoints:

1. A reservation listing endpoint so Mozrest can retrieve your bookings for a given date.
2. A walk-in creation endpoint so Mozrest can create a seated booking in your system when a POS check has no matching reservation.

A third, optional endpoint — reservation status change — lets Mozrest mark a reservation as seated when a check is matched, and as finished once the final check is delivered.

Mozrest connects to these endpoints through a dedicated adapter. If your API already exposes equivalent endpoints with different paths or field names, contact us — we map your existing contract as long as it provides the fields below.

---

How Check Matching Works

Automatic matching. When a new check arrives from the POS, Mozrest retrieves your reservations around the check's opening time and scores the candidates on time proximity, party size, and table assignment. When a candidate scores high enough, the check is linked automatically — and, if you expose the status-change endpoint, the reservation is marked as seated.

Manual matching. Checks that cannot be matched automatically appear in the Mozrest check-matching tool, where venue staff see open POS checks next to the day's reservations and can match, unmatch, or rematch them.

Walk-ins. When a check belongs to a guest who never booked, staff create a walk-in from the tool: Mozrest calls your walk-in creation endpoint to create a seated booking in your RMS, then links the check to it.

Spend data. As soon as a check is matched — automatically, manually, or via a walk-in — Mozrest sends it to your webhook endpoint with bookingId set, and keeps it updated until the check is closed or voided.

---

Reservation Listing Endpoint

Mozrest calls this endpoint to retrieve your bookings for a given date — it powers both automatic matching and the reservation list shown in the check-matching tool.

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

Query parameters

Parameter	Type	Description
dateFrom	String	Start date, YYYY-MM-DD
dateTo	String	End date, YYYY-MM-DD (same as dateFrom for a single day)
limit	Integer	Page size
offset	Integer	Pagination offset

Response

{
  "bookings": [
    {
      "id": "988771",
      "date": "2026-07-03",
      "time": "20:30",
      "partySize": 4,
      "status": "seated",
      "tables": ["28c3ce8b-8c10-4a64-8099-f0dffcc549a8"],
      "customerId": "55211",
      "contact": {
        "firstname": "John",
        "lastname": "Doe",
        "telephone": "34646223399",
        "email": "john.doe@mail.com"
      }
    }
  ],
  "total": 42
}

Field	Type	Required	Description
id	String	Yes	Your booking identifier. This is the value Mozrest sends back as bookingId on check webhooks
date	String	Yes	Booking date, YYYY-MM-DD
time	String	Yes	Booking time, HH:MM
partySize	Integer	Yes	Number of guests
status	String	Yes	Your reservation status (e.g. confirmed, seated)
tables[]	Array	No	Table IDs assigned to the booking. Must be the same IDs returned by your table listing endpoint — used for matching
customerId	String	No	Your guest/customer identifier
contact	Object	No	Guest name, phone, and email — shown to staff in the check-matching tool

---

Walk-In Creation Endpoint

Mozrest calls this endpoint when venue staff create a walk-in from the check-matching tool for a check without a reservation.

• Method: POST
• Path: /venue/{venueId}/bookings
• Authentication: Bearer token

Request

{
  "date": "2026-07-03",
  "time": "20:45",
  "partySize": 2,
  "status": "seated",
  "walkIn": true
}

Field	Type	Description
date	String	Booking date, YYYY-MM-DD (taken from the check's opening time)
time	String	Booking time, HH:MM
partySize	Integer	Number of guests
status	String	Always seated — the guest is already at the table
walkIn	Boolean	Always true

Response

The response must include the identifier of the created booking — Mozrest immediately links the POS check to it.

{
  "id": "988772"
}

The endpoint must accept the booking even when it falls outside your normal availability rules — the guest is already seated.

---

Reservation Status Change Endpoint (Optional)

When available, Mozrest uses this endpoint to keep your reservation lifecycle in sync with the POS: the reservation is marked as seated when a check is matched, and as finished once the final check is delivered.

• Method: PATCH
• Path: /venue/{venueId}/bookings/{bookingId}/status
• Authentication: Bearer token

Request

{
  "status": "seated"
}

status value	When Mozrest sends it
seated	A POS check was matched to the reservation
finished	The final check for the reservation was closed and delivered