Skip to main content
This page is the exhaustive reference for the integration. Use it to answer “does X come back?” and “why did my change disappear?”.

From EatNow to NowOS

EatNow sends a reservation to the till as soon as it is confirmed, then on every change. Sending is automatic and immediate.

When a push happens

Reservation taken on the portal, by phone, by the WhatsApp AI agent, by a prescriber, through Reserve with Google, or typed in by your team.
Status, covers, tables, internal note, guest, time. Including changes the guest makes themselves from their confirmation link.
A deposit or prepayment collected, a card imprint captured or released.
Automatic table assignment, automatic no-show at the end of service, automatic close-out.
A reservation deleted in EatNow is first pushed to the till as cancelled, so it disappears from the panel too.

What each push contains

Status mapping

Pending reservations are never sent to the till. That’s deliberate: until a request is accepted, it shouldn’t clutter the floor plan or hold a table hostage for the floor.

From NowOS to EatNow

The till tells EatNow about everything happening on the floor. Every message is cryptographically verified (thanks to the signing secret) and processed exactly once, even if it’s redelivered.
A gesture made on the till updates the status in EatNow, but never triggers your guest communications (email, WhatsApp) or refunds. To notify or refund a guest, make the gesture from EatNow.The one exception is the card imprint, which is released or charged automatically — see Deposits, prepayments and imprints.

The precedence rules

Understanding these four rules explains 99% of the behaviour.
On shared fields (covers, internal note, tables, status), the most recent change wins, regardless of which system it was made in. There is no “priority side”: there is a chronological order.
When the floor changes covers, tables or the note on the till, EatNow applies the change then sends it back to the till for confirmation. That’s what guarantees the two systems never drift apart, even on fields both sides can edit.It also explains a behaviour that can surprise: if EatNow refuses a change (see rule 3), the till visibly reverts to EatNow’s value. That’s not a bug — that’s the refusal showing.
A Done, No-show, Cancelled or Rejected reservation is frozen. A late event from the till (a bill that lingered, a redelivered message) can no longer resurrect or modify it.If the floor corrects covers or the note on an already-closed reservation, EatNow refuses and the till reverts to EatNow’s value.
If the floor assigns three tables to a reservation and just one of the three isn’t paired in EatNow, the change is refused as a whole. EatNow never seats a party on “the tables it happened to recognise”: that would silently contradict the floor.

What does not sync

For completeness, here’s what deliberately stays on one side: