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

---

Step 1 — Check that the venue allows it

Endpoint: 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 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

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

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.

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.

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