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

# Ticket Flow

> How the POS manages a table from seating to ticket close, for both Walk-Ins and pre-existing reservations.

## Overview

```mermaid theme={null}
flowchart TD
    A1(["Walk-In"]) --> B1["Create Walk-In booking"]
    A2(["Pre-existing booking"]) --> B2["Seat the table"]

    B1 --> G
    B2 --> G

    G["Close ticket"]
    G --> Z(["End"])

    style A1 fill:#28a745,stroke:#1e7e34,color:#ffffff
    style A2 fill:#28a745,stroke:#1e7e34,color:#ffffff
    style Z fill:#28a745,stroke:#1e7e34,color:#ffffff
```

***

## Walk-In

**Endpoint:** [`POST /bookings/walk-ins`](/pos-api/methods/bookings/create-walk-in)

Creates a booking directly in `SEATED` status — no availability check required. Use this when a customer arrives without a prior reservation.

`ticketExternalId` acts as an idempotency key — if your POS sends the same ticket ID twice, Restoo returns the existing Walk-In instead of creating a duplicate.

***

## Pre-existing booking — seating the table

**Endpoint:** [`PUT /bookings/{uuid}/status`](/pos-api/methods/bookings/update-status)

When a customer with a reservation arrives, seat the table by transitioning the booking to `SEATED`. Valid source statuses: `CONFIRMED`, `ARRIVED`, `WAIT_LIST_WALK_IN`.

***

## Ticket transfer (optional)

**Endpoint:** [`PUT /bookings/{uuid}/tickets/transfer`](/pos-api/methods/bookings/tickets-transfer)

```mermaid theme={null}
flowchart TD
    A(["Ticket on wrong booking"]) --> B["Transfer ticket to correct booking"]
    B --> Z(["Continue →"])

    style A fill:#4a90d9,stroke:#2c6fad,color:#ffffff
    style Z fill:#4a90d9,stroke:#2c6fad,color:#ffffff
```

Use this when a POS ticket was opened on the wrong booking and needs to be moved to the correct one. See the endpoint reference for the source and destination parameter conventions.

This endpoint is rarely needed in a standard flow.

***

## Service progression (optional)

**Endpoint:** [`PUT /bookings/{uuid}/status`](/pos-api/methods/bookings/update-status)

```mermaid theme={null}
flowchart TD
    A(["Table seated"]) --> B{"Send DESSERTS?"}
    B -- Yes --> C["DESSERTS"]
    B -- No --> D
    C --> D{"Send ACCOUNT_SENT?"}
    D -- Yes --> E["ACCOUNT_SENT"]
    D -- No --> F
    E --> F(["Close ticket →"])

    style A fill:#4a90d9,stroke:#2c6fad,color:#ffffff
    style F fill:#4a90d9,stroke:#2c6fad,color:#ffffff
```

Track optional service stages before closing the ticket. Both `DESSERTS` and `ACCOUNT_SENT` are independent — neither is required, and each can be sent without the other. Financial data is only sent when closing the ticket.

***

## Updating tables or party size mid-service

Use the dedicated update endpoints if the table assignment or party size changes during service:

* [`PUT /bookings/{uuid}/tables`](/pos-api/methods/bookings/update-tables) — reassign tables
* [`PUT /bookings/{uuid}/size`](/pos-api/methods/bookings/update-size) — update party size

***

## Close ticket

**Endpoint:** [`PUT /bookings/{uuid}/tickets/close`](/pos-api/methods/bookings/tickets-close)

Closes the POS ticket and moves the booking to `ATTENDED` or `ACCOUNT_PAID` depending on the integration configuration. See the endpoint reference for the full financial summary structure.