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

# Update Booking Flow

> How to modify an existing booking — party size, date/time, notes, and more.

Use this endpoint when a customer needs to change details of an existing booking.

***

## Overview

```mermaid theme={null}
flowchart TD
    A(["Start"]) --> FEAT{"Venue allows updates?"}

    FEAT -- No --> ALT(["Cancel and book again →"])
    FEAT -- Yes --> R["Get Booking"]

    R --> B{"Availability affected?"}

    B -- Yes --> C(["Run Availability Flow →"])
    B -- No --> D

    C --> D["Update Booking"]

    D --> E{"Conflict?"}
    E -- BOOKING_IS_OUTDATED --> RETRY["Re-apply changes and retry"]
    RETRY --> D

    E -- No --> Z(["Booking updated"])

    style A fill:#28a745,stroke:#1e7e34,color:#ffffff
    style Z fill:#28a745,stroke:#1e7e34,color:#ffffff
    style C fill:#4a90d9,stroke:#2c6fad,color:#ffffff
    style ALT fill:#4a90d9,stroke:#2c6fad,color:#ffffff
```

***

## Step 1 — Check that the venue allows it

**Endpoint:** [`Get Tenant Profile`](/restoo-api/tenant/get-tenant-profile)

Modification is a feature the venue can switch off, so check
`features.allowExternalBookingUpdates.isEnabled` before offering the operation
at all. Calling [`Update Booking`](/booking-channel-api/methods/bookings/update)
with it disabled returns HTTP 403 `FEATURE_PUBLIC_BOOKING_UPDATES_NOT_ENABLED`,
or `FEATURE_PUBLIC_BOOKING_UPDATES_NOT_AVAILABLE` when the venue's plan does not
include the feature.

When it is `false`, the customer's way out is to cancel and book again: submit
the cancellation with reason `UPDATE_BOOKING` and start a new booking.
Cancelling is exempt from the flag, so it works either way.

***

## Step 2 — Read the current booking

**Endpoint:** [`Get Booking`](/booking-channel-api/methods/bookings/retrieve)

Six fields must travel on the update whether or not you are changing them, and
the stored booking is the only place to get their current values.

***

## Step 3 — Re-check availability (when the change affects it)

Changing the party size, the date and time, the experience, the add-ons or the
status re-runs the availability check on the server, and a combination with no
slot fails with HTTP 409 `BOOKING_AVAILABILITY_NOT_FOUND`. Walk the
[Availability Flow](/booking-channel-api/availability-flow) first, so you offer
the customer something that exists rather than discovering it here.

Pass `excludeBookingUuid` with the UUID of the booking being modified, or the
booking is counted against the availability of the slot it is moving to.

***

## Step 4 — Send the update

**Endpoint:** [`Update Booking`](/booking-channel-api/methods/bookings/update)

These six are required on every request:

| Field                   | Send                                                                           |
| :---------------------- | :----------------------------------------------------------------------------- |
| `customer`              | The stored customer, including `name`, `hasGdprConsent` and `acceptsMarketing` |
| `date` and `time`       | The stored `bookingAt`, split in two                                           |
| `pax` and `paxChildren` | The stored counts, unless that is the change                                   |
| `status`                | The stored status, unless you mean to move it                                  |

Every other field is optional in the real sense: omit it and it keeps its stored
value.

<Warning>
  Both consents are required, so every update rewrites them. `acceptsMarketing`
  is the dangerous one: filling it in with `false`, the usual form default,
  silently withdraws a consent the customer had given. `hasGdprConsent` fails
  loudly instead — `false` is not accepted — so send the `true` you read from
  the booking.
</Warning>

### Which statuses you can move the booking to

`status` is the status you are asking for, not a description of the current one:
the value you send is what the availability check evaluates.

A booking can only be modified while it is in one of these four statuses. Any
other — one that has already arrived or been seated, for instance — returns
HTTP 409 `STATUS_NOT_VALID_TO_UPDATE_PUBLIC_BOOKING`.

| Current status                               | You can move it to                                   |
| :------------------------------------------- | :--------------------------------------------------- |
| `CONFIRMED`                                  | `REQUESTED`, `PENDING_WAIT_LIST_BOOKING`, `CANCELED` |
| `REQUESTED`, `PENDING_MERCHANT_CONFIRMATION` | `CANCELED`                                           |
| `PENDING_WAIT_LIST_BOOKING`                  | `CANCELED`, `CONFIRMED`                              |

Any other target returns HTTP 409 `BOOKING_STATUS_NOT_VALID`.

To cancel, use the [Cancellation Flow](/booking-channel-api/cancellation-flow)
rather than a status change — it quotes the penalty first.

### Handling concurrent modifications

If two systems attempt to update the same booking simultaneously, the second request will receive a `BOOKING_IS_OUTDATED` error (HTTP 409).

To recover: fetch the current state with [`Get Booking`](/booking-channel-api/methods/bookings/retrieve), re-apply the intended changes, and retry the update.

***

## Step 5 — Handle the response

On success, the response includes the updated booking object and a `redirectUrl`. If the booking has a cancellation policy that requires re-signing after the change, redirect the customer to `redirectUrl` to complete the signature — the same rules apply as in the [Booking Creation Flow](/booking-channel-api/booking-creation-flow#redirect-the-customer).