Table reservations and booking management
List bookings
List bookings with optional filtering and pagination
Permissions: 🔵 bookings.read
query Parameters
locationIdFilter by location ID
tableIdFilter by table ID
statusBooking status
bookingDateFilter by exact date
startDateFilter by start date (inclusive)
endDateFilter by end date (inclusive)
userIdFilter by user ID
confirmationCodeFilter by confirmation code
bookingSourceSource of the booking
pagePage number
limitItems per page
List bookings › Responses
Default Response
statusCreate booking
Create a new booking. The response always includes a linked tab (the booking creates a pre_arrival tab atomically) so integrations can begin committing orders against data.tab.id immediately. Pass seatImmediately: true in the body to atomically transition the new booking to seated and open its tab in a single call (recommended for walk-in flows). When seatImmediately is true and the booking has unpaid required items or its table already has an open tab, the booking is still created but seating is skipped and seatWarning is returned.
Permissions: 🟢 bookings.create
Create booking › Request Body
locationIdLocation ID
bookingDateDate of the booking
startTimeStart time (HH:MM)
endTimeEnd time (HH:MM)
timezoneTimezone (e.g., Europe/Stockholm)
guestCountNumber of guests (0 allowed for walk-ins where staff opens a tab for drinks-only / non-food guests)
tableIdLegacy single-resource ID (kept for backwards compat). When tableIds is provided it takes precedence; otherwise tableId is folded into a single-element resource set.
tableIdsMulti-resource booking (Phase 40). Array of storefront_qr_code UUIDs to reserve. The first entry is treated as primary. When provided, supersedes tableId.
defaultTabStrategyTab strategy locked in at booking time (Phase 40). single (default) — one shared tab across all reserved resources. per_resource — one tab per resource opened on seat.
primaryUserIdPrimary guest user ID (null for walk-ins)
occasionOccasion for the booking
specialRequestsGuest special requests
internalNotesStaff-only notes
paymentTypePayment type required for booking
depositAmountCentsDeposit amount in cents
bookingSourceSource of the booking
guestNameGuest contact name
guestEmailGuest contact email
guestPhoneGuest contact phone
seatImmediatelyIf true, immediately seat the booking after creation. Requires a table assignment. Will check for conflicting open tabs on the table.
Create booking › Responses
Default Response
statusUpdate booking
Update an existing booking
Permissions: 🟠bookings.update
path Parameters
idBooking ID
Update booking › Request Body
tableIdLegacy single-resource ID (kept for backwards compat). When tableIds is provided it takes precedence; otherwise tableId replaces the booking resource set with a single entry.
tableIdsMulti-resource booking (Phase 40). Array of storefront_qr_code UUIDs that replaces the booking resource set. The first entry is treated as primary. When provided, supersedes tableId.
defaultTabStrategyChange the booking tab strategy pre-seat (Phase 40). Staff can flip between single and per_resource until the booking is seated.
confirmRemoveActiveTabGates the destructive path in R8 (Phase 40): when shrinking tableIds would remove a resource that already has an active tab, the API only proceeds if this flag is true. Without it, the update is rejected with a 409 so staff can confirm.
bookingDateDate of the booking
startTimeStart time
endTimeEnd time
guestCountNumber of guests (0 allowed for walk-ins where staff opens a tab for drinks-only / non-food guests)
occasionOccasion for the booking
specialRequestsGuest special requests
internalNotesStaff-only notes
paymentTypePayment type required for booking
depositAmountCentsDeposit amount in cents
Update booking › Responses
Default Response
statusCancel booking
Cancel a booking
Permissions: ⚪ bookings.manage
path Parameters
idBooking ID
Cancel booking › Request Body
reasonCancellation reason
closeTabWhether to close the linked pre-arrival tab. Defaults to true.
Cancel booking › Responses
Default Response
statusAdd booking member
Add a member to a booking
Permissions: ⚪ bookings.manage
path Parameters
idBooking ID
Add booking member › Request Body
userIdguestNameguestEmailrsvpStatusAdd booking member › Responses
Default Response
statusUpdate booking member
Update a booking member RSVP status
Permissions: ⚪ bookings.manage
path Parameters
idBooking ID
memberIdMember ID
Update booking member › Request Body
rsvpStatusUpdate booking member › Responses
Default Response
statusSeat booking
Mark a booking as seated. Optionally create a linked tab for the booking.
Permissions: ⚪ bookings.manage
path Parameters
idBooking ID
Seat booking › Request Body
tabIdOptional existing tab ID to link
createTabIf true, creates a new tab linked to this booking. The tab will be associated with the booking's primary user and table.
Seat booking › Responses
Default Response
statusSplit booking into per-resource tabs
Phase 40 R6 — convert a seated single-strategy multi-resource booking into per-resource tabs. Creates N-1 new tabs (one per non-primary resource that does not yet have its own tab). The existing primary tab and any items on it are preserved. bookings.default_tab_strategy is NOT mutated — it records the original choice. Idempotent: re-running only creates tabs for resources missing one.
Permissions: ⚪ bookings.manage
path Parameters
idBooking ID
Split booking into per-resource tabs › Responses
Default Response
statusUnseat booking
Undo a seat operation. Reverts the booking to its prior status (checked_in or confirmed), puts the linked tab back to pre_arrival, and reverses all kitchen dispatches advanced by seating. Refuses if purchases exist, additional orders were placed, or any dispatch is past accepted.
Permissions: ⚪ bookings.manage
path Parameters
idBooking ID
Unseat booking › Request Body
reasonWhy the booking is being unseated (shown on the kitchen correction ticket).
Unseat booking › Responses
Default Response
statusCancel booking by confirmation code
Public endpoint: cancel a booking using confirmation code (no auth required)
path Parameters
codeBooking confirmation code
Cancel booking by confirmation code › Responses
Default Response
statusRSVP to booking
Public endpoint: RSVP to a booking using confirmation code (no auth required)
RSVP to booking › Request Body
confirmationCodeguestNamersvpStatusguestEmailRSVP to booking › Responses
Default Response
statusGet availability
Get available booking slots for a date and party size
Permissions: 🔵 bookings.read
path Parameters
locationIdLocation ID
query Parameters
dateDate to check availability
partySizeNumber of guests
bookingGroupIdOptional booking group ID to filter availability by group schedule, table pool, and settings
Get availability › Responses
Default Response
statusGet bookings by table
Get bookings grouped by table for a specific date. Useful for table map display in POS.
Permissions: 🔵 bookings.read
path Parameters
locationIdLocation ID
query Parameters
dateDate to fetch bookings for (YYYY-MM-DD)
Get bookings by table › Responses
Default Response
statusWebhook: Booking created
Fired when a new booking is created. The full booking object is spread into data.
This is an outbound webhook event. Karma POSTs this payload to the URL you registered via POST /api/v1/webhooks/subscriptions. Your endpoint should respond 2xx within 30 seconds to acknowledge delivery.
Webhook: Booking created › Request Body
idUnique webhook delivery ID
eventresourceresourceIdString ID of the affected resource
timestampISO 8601 timestamp when the event was emitted
apiVersionWebhook: Booking created › Responses
Acknowledged. Karma considers any 2xx response a successful delivery; non-2xx triggers retry with exponential backoff.
Webhook: Booking confirmed
Fired when a booking transitions to confirmed. The full updated booking is spread into data.
This is an outbound webhook event. Karma POSTs this payload to the URL you registered via POST /api/v1/webhooks/subscriptions. Your endpoint should respond 2xx within 30 seconds to acknowledge delivery.
Webhook: Booking confirmed › Request Body
idUnique webhook delivery ID
eventresourceresourceIdString ID of the affected resource
timestampISO 8601 timestamp when the event was emitted
apiVersionWebhook: Booking confirmed › Responses
Acknowledged. Karma considers any 2xx response a successful delivery; non-2xx triggers retry with exponential backoff.
Webhook: Booking updated
Only the modified fields appear in changes.
This is an outbound webhook event. Karma POSTs this payload to the URL you registered via POST /api/v1/webhooks/subscriptions. Your endpoint should respond 2xx within 30 seconds to acknowledge delivery.
Webhook: Booking updated › Request Body
idUnique webhook delivery ID
eventresourceresourceIdString ID of the affected resource
timestampISO 8601 timestamp when the event was emitted
apiVersionWebhook: Booking updated › Responses
Acknowledged. Karma considers any 2xx response a successful delivery; non-2xx triggers retry with exponential backoff.
Webhook: Booking cancelled
Fired when a booking is cancelled.
This is an outbound webhook event. Karma POSTs this payload to the URL you registered via POST /api/v1/webhooks/subscriptions. Your endpoint should respond 2xx within 30 seconds to acknowledge delivery.
Webhook: Booking cancelled › Request Body
idUnique webhook delivery ID
eventresourceresourceIdString ID of the affected resource
timestampISO 8601 timestamp when the event was emitted
apiVersionWebhook: Booking cancelled › Responses
Acknowledged. Karma considers any 2xx response a successful delivery; non-2xx triggers retry with exponential backoff.
Webhook: Booking seated
Fired when guests are seated. Includes the full booking and an optional tabId if seating opened a tab.
This is an outbound webhook event. Karma POSTs this payload to the URL you registered via POST /api/v1/webhooks/subscriptions. Your endpoint should respond 2xx within 30 seconds to acknowledge delivery.
Webhook: Booking seated › Request Body
idUnique webhook delivery ID
eventresourceresourceIdString ID of the affected resource
timestampISO 8601 timestamp when the event was emitted
apiVersionWebhook: Booking seated › Responses
Acknowledged. Karma considers any 2xx response a successful delivery; non-2xx triggers retry with exponential backoff.
Webhook: Booking unseated
Fired when seating is undone. Lists all kitchen dispatches that were reversed (each will also fire order.reversed).
This is an outbound webhook event. Karma POSTs this payload to the URL you registered via POST /api/v1/webhooks/subscriptions. Your endpoint should respond 2xx within 30 seconds to acknowledge delivery.
Webhook: Booking unseated › Request Body
idUnique webhook delivery ID
eventresourceresourceIdString ID of the affected resource
timestampISO 8601 timestamp when the event was emitted
apiVersionWebhook: Booking unseated › Responses
Acknowledged. Karma considers any 2xx response a successful delivery; non-2xx triggers retry with exponential backoff.
Webhook: Booking completed
Fired when a booking is marked complete. The full booking object is spread into data.
This is an outbound webhook event. Karma POSTs this payload to the URL you registered via POST /api/v1/webhooks/subscriptions. Your endpoint should respond 2xx within 30 seconds to acknowledge delivery.
Webhook: Booking completed › Request Body
idUnique webhook delivery ID
eventresourceresourceIdString ID of the affected resource
timestampISO 8601 timestamp when the event was emitted
apiVersionWebhook: Booking completed › Responses
Acknowledged. Karma considers any 2xx response a successful delivery; non-2xx triggers retry with exponential backoff.
Webhook: Booking marked no-show
Fired when a booking is marked as no-show. The full booking is spread into data.
This is an outbound webhook event. Karma POSTs this payload to the URL you registered via POST /api/v1/webhooks/subscriptions. Your endpoint should respond 2xx within 30 seconds to acknowledge delivery.
Webhook: Booking marked no-show › Request Body
idUnique webhook delivery ID
eventresourceresourceIdString ID of the affected resource
timestampISO 8601 timestamp when the event was emitted
apiVersionWebhook: Booking marked no-show › Responses
Acknowledged. Karma considers any 2xx response a successful delivery; non-2xx triggers retry with exponential backoff.