> ## Documentation Index
> Fetch the complete documentation index at: https://restoo.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Before you start

> Prerequisites and important behaviors to understand before building your POS integration.

<Note>
  This guide assumes familiarity with [Restoo Key Concepts](/getting-started/key-concepts).
</Note>

## Table mapping

Before the integration starts, it is necessary to mutually agree on which [Table](/getting-started/key-concepts#table) identifier will be used in calls to the Restoo API:

* **Public name** — Requires Table public names to be exactly the same in both Restoo and the POS.
* **Restoo ID** — Table mapping must be done in the POS during initial setup.
* **POS ID** — Table mapping must be done in Restoo during initial setup.

<Warning>
  Restoo allows to have different [Floor
  Plan](/getting-started/key-concepts#floor-plan) and Tables for each day and/or
  Shift, so the same Table public name on Restoo may have different IDs.
</Warning>

*Example: The Restoo Table with public name “10” may have ID 54 for the lunch Shift on March 20, 2025, but ID 96 for the Shift on March 21, 2025.*

## Multi-Table management

Restoo supports bookings that occupy more than one Table.

*Example: Steve Jobs has a booking for 20 guests, occupying tables 10, 11, 12, and 13.*

**If the POS does not support multi-table management**, the following logic will apply to avoid overbooking based on the current state of the booking:

* **If the booking has no table assigned**, the table sent by the POS will be assigned.
* **If the booking has only one table assigned**, it will be replaced with the one sent by the POS.
* **If the booking has more than one table assigned**, the request will be rejected with an error.

## Walk-Ins

It is highly recommended that [Walk-Ins](/getting-started/key-concepts#booking-types) can be created both from the POS and from Restoo.

## Restoo Ticket Management

Only one ticket can be associated with each booking in Restoo.

## Best Practices & Conflict Resolution

* **Handling Disconnections:** In the event of a network failure, the POS should queue updates and retry the synchronization once the connection is restored to avoid data gaps.
* **Unlinking Tickets:** If a ticket is voided or deleted in the POS, the corresponding booking in Restoo should ideally revert to its previous status or be flagged for manual review by the staff.
* **Concurrency:** In cases of simultaneous updates, Restoo remains the authority for booking logistics (time, party size, table), while the POS is the authority for ticket financials and consumption.