# Orders

Create and manage orders

## Create an order — one or more independent bookings, across any platform

 - [POST /v1/orders](https://docs.bookabletech.com/apis/production/listingsapiv1/orders/createorder.md): Creates an order containing one or more bookings. Each item is resolved and
booked independently — there is no cross-item transaction. A failure on
one item (e.g. the venue/event on one platform is fully booked) does not
block or roll back the others. The response carries one OrderItemResult
per requested item, preserving request order — mirroring how
POST /v1/availabilities reports one result per compositeId.

Because every item is self-sufficient via its own compositeId (which embeds
VenueGroupId + RmsSlug), a single order can span multiple venues and even
multiple RMS platforms (e.g. one item on Collins, another on Zonal) — there is
no top-level listingId constraining the order to one platform.

Each OrderItem is unified (no capability field, no oneOf) — quantity
carries the count for either capability (covers for a table reservation, ticket
count for an event-ticket line); time additionally applies to table
reservations. Capability is resolved server-side from the compositeId's RMS
slug, not from which fields are populated. An order's items may mix
capabilities and platforms freely.

## Update one or more bookings within an order

 - [PATCH /v1/orders/{orderId}](https://docs.bookabletech.com/apis/production/listingsapiv1/orders/updateorder.md): Partial update — each OrderItemUpdate only carries the fields being changed;
anything omitted keeps its current value. Items are resolved and updated
independently, same isolation model as POST /v1/orders: a failure on one
item does not block the others.

Capability (table reservation vs. event ticket) is resolved server-side from the
existing booking, not from the request — every field below applies uniformly to
either capability at the API level, even where the RMS-side effect currently
differs (noted per field).

compositeId moves the booking to a different bookable product — the same
identifier used everywhere else (Bookable.compositeId, the only thing taken
from a listing's bookableProducts[]), not a ticket-specific field. Supported for
both capabilities: for event tickets it changes the ticket type (the
compositeId's 4th segment); for table reservations it changes the booked
product/space. The new compositeId must reference the same venue group, RMS and
venue/event as the booking's current product — only the trailing product/ticket-type
segment may differ; a cross-venue or cross-event move is rejected (400 ORDER-N-007).

firstName/lastName/email/phone update the guest's details, either capability.

Preorders (table-reservation only in practice — event tickets have no preorder
concept, these fields are accepted but a no-op for them today): preorders is a
full replacement of the current preorder set (omit to leave unchanged, send
empty arrays to clear). preorderChanges is the incremental alternative — add or
remove specific packages/menus without resending the rest; mutually exclusive with
preorders on the same item (400 ORDER-N-008).

## Cancel bookings within an order, or the entire order

 - [DELETE /v1/orders/{orderId}](https://docs.bookabletech.com/apis/production/listingsapiv1/orders/deleteorder.md): Cancels the bookings listed in bookingIds. When bookingIds is omitted or
empty, cancels every booking belonging to orderId. Each cancellation is
independent — one failure does not block the others.