> ## 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.

# Introduction

> Why and how to integrate Restoo with your POS system?

## General Integration Objectives

The primary goal of integrating Restoo with a POS (Point of Sale) system is to create a seamless data ecosystem that minimizes friction for restaurant staff.

* **Streamline Operations** — Synchronize booking data bi-directionally and in real-time to eliminate manual data entry and double-booking risks.
* **Unified Data Insights** — Enrich customer profiles and sales reports by merging Restoo’s booking data with the POS consumption data.

## Integration Tiers & Flexibility

At Restoo, we understand that every POS system has a unique technical architecture and varying levels of API capabilities. For this reason, we offer a **flexible integration framework** designed to adapt to different technical environments.

While this document outlines the **"Ideal Integration"** — representing the comprehensive set of features requested by Restoo merchants to maximize efficiency — we also support modular implementations. Partners can choose to implement a subset of these features based on their system's current capabilities:

* **Modular Approach:** If your POS does not support a specific feature (e.g., native booking management), the integration can focus on core functionalities like automated ticket opening and status synchronization.
* **Scalable Roadmap:** Partners can start with a baseline integration (e.g., POS-to-Restoo status updates) and expand to full bidirectional synchronization over time.
* **Custom Mapping:** We provide flexible logic to handle cases where POS and Restoo workflows might differ slightly.

Our goal is to build the best possible experience for our mutual clients, regardless of the starting point of the technical integration.

## Data Ownership (Source of Truth)

To ensure data integrity, the integration follows a clear hierarchy of responsibility:

* **Restoo as the SSoT for Bookings** — Restoo remains the primary source of truth for all booking-related data, including guest information, inventory availability, and table assignments.
* **POS as the SSoT for Tickets** — The POS system remains the primary source of truth for all transactional data, including itemized consumption, ticket status (e.g., desserts, bill sent), and final payments.

## Operational Workflows

A core objective of this integration is flexibility in guest reception. Both Bookings and Walk-Ins can be managed from either system depending on the restaurant's operational model:

* **Hostess-led Reception (Restoo)** — Essential for venues with a dedicated Hostess. Guests are greeted and seated via Restoo, which automatically triggers the opening of a ticket in the POS.
* **Staff-led Reception (POS)** — For venues where servers seat guests directly. Opening a ticket in the POS automatically notifies Restoo to update table availability and log the guest entry.

***

## Synchronized Properties

To achieve a high-level integration, we aim to synchronize as much data as possible across the following categories:

### Booking & Walk-Ins

* **Customer Profile:** Linked guest information.
* **Logistics:** Date, time, party size (adults/children), and assigned table(s).
* **Live Status:** Tracking the guest journey (e.g., "Confirmed", "Arrived", "Seated", "Desserts", "Bill Sent", "Paid", "Attended", "Canceled").
* **Extras:** Associated experiences, add-ons, and promotions.
* **Notes:** Private booking notes, specific customer requests, and allergy alerts.
* **Financials:** Guarantees, prepayments, or gift vouchers redeemed via either Restoo or the POS.

### Customer (CRM)

* **Identity:** Full name, phone number, and email address.
* **Segmentation:** VIP status and private internal customer notes.

### Ticket Data

* **Revenue:** Final amount, tip, and detailed itemized breakdown of products consumed.
* **Staff:** Assigned server/waiter.

***

## Trigger Events

For an optimal user experience, all events should be communicated between systems in **real-time** using **[Webhooks](/getting-started/webhooks)** (recommended) or optimized polling.

### Flow: Restoo → POS

The following events occurring in Restoo should trigger an update in the POS:

| Event                         | Action in POS                                                                                                                                                                                 |
| :---------------------------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Booking Created/Updated**   | *Optional:* Syncs scheduled bookings for POS systems with a native booking module.                                                                                                            |
| **Booking Check-in**          | When a guest is marked as "Seated" in Restoo, a new ticket is automatically opened in the POS. If the table is already occupied, the system prompts the user to merge or create a new ticket. |
| **Walk-In Creation**          | Automatically opens a ticket for unplanned guests seated via Restoo. If the table is occupied in the POS, it prompts for manual resolution.                                                   |
| **Booking & Walk-In Updates** | Any change (e.g., table assignment, party size) in Restoo is immediately reflected in the active POS ticket.                                                                                  |

### Flow: POS → Restoo

The following events occurring in the POS should trigger an update in Restoo:

| Event                                | Action in Restoo                                                                                                                                                                                          |
| :----------------------------------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Ticket / Walk-In Created/Updated** | If a table is opened in the POS, Restoo creates a "Walk-In" entry. If the table is already reserved and/or occupied in Restoo, it prompts the user to link the ticket to the existing booking or Walk-In. |
| **Status Updates**                   | When the "Dessert" course is fired or the "Bill/Subtotal" is printed, Restoo automatically updates the booking status to reflect table progress.                                                          |
| **Payment & Closing**                | Once the bill is settled, the Restoo booking is marked as "Paid" or "Attended," and the consumption data is logged into the customer’s history.                                                           |
| **Booking Management**               | *Optional:* If the POS handles bookings, any creation or deletion is synced back to the Restoo master calendar.                                                                                           |