Skip to content
Last updated

Changelog

All notable changes to this project will be documented in this file.

The format is based on Keep a Changelog, and this project adheres to Semantic Versioning.

[Bookings API - v8.1.0] - 2026-10-16

Deploy on production

Added

Bookings API v8.1.0

  • dateTime on bookings and availability: the real moment the reservation starts, in the venue's local time with its UTC offset (RFC 3339). date and time stay on the venue's trading day, so a 00:30 slot at the end of a Saturday evening has Saturday's date but starts on Sunday.
    • GET /venues/{compositeId}/availability: new times[].dateTime. Send it back unchanged as dateTime when you book.
    • POST /venues/{compositeId}/booking and PUT /venues/bookings/{bookingId}: new dateTime. date and time are no longer required: send dateTime, or both date and time. If you send both forms they must agree (BOOK-N-018). Missing both: BOOK-N-019. No UTC offset: BOOK-N-020.
    • Booking.dateTime in responses. Selectable with fields.
  • GET /venues/{compositeId}/availability: new startDateTime / endDateTime query parameters (UTC offset required, encode + as %2B). Use them instead of date / startTime / endTime. endDateTime is inclusive, needs startDateTime, and the window can be at most 48 hours. A window that crosses midnight also returns the late-night slots of the evening before. date is now only required when startDateTime is not sent. New errors AVAIL-N-009 (the two forms disagree) and AVAIL-N-010 (bad window).
  • Venue.bookingRequirements.company on GET /venues/{venueId} (partners mapped to the venue's operator only): your channel's company config at this operator — mode (none, single, list), company, companyNames and required. In list mode a company not in the list fails with 422 BOOK-N-015. If the list is required, a missing company fails with 422 BOOK-N-016.
  • Booking.payments: the payments recorded in Bookable for the booking, oldest first (id, optionType, amount in pence, status, updatedAt). Returned by GET /venues/bookings, GET /venues/bookings/{bookingId}, PATCH and PUT .../status. Not returned on create or full update. If it is missing, no payment is recorded in Bookable — that does not mean the booking is unpaid. /payments cannot be patched.
  • GET /venues/bookings new filters: productName (partial, case-insensitive), productCategory (1–10 slugs from GET /venues/category), tmsCreatedDateFrom / tmsCreatedDateTo (when the booking was made in the TMS, inclusive, UTC). The description now also explains which TMS bookings are listed and how to count bookings (pageSize=1, read meta.totalItems).
  • media on spaces (products[].spaces[] and availability spaces): the space's own photos and videos, then venue items assigned to it. Empty when it has none — use the venue's media.
  • BOOK-N-017 (422, Zonal): the spaceId is not offered by the product. Use a space from this product's availability response.
  • Operator-only additions (venue-group callers): Booking.tmsTables and Booking.autoConfirmed (Collins) on GET /venues/bookings; times[].unavailableRules, excludedPackages and excludedMenus on availability with includeUnavailable=true when operator staff act as a partner through X-Partner-Reference. Partners never receive rule details.
  • fields now accepts dateTime and payments on bookings; depositAmount, actualGuests, actualSpend, area, tmsTables and autoConfirmed on GET /venues/bookings; bookingRequirements on GET /venues/{venueId}. See sparse fieldsets.

Changed

  • BREAKING CHANGE: Venue.photos (a list of URLs) is removed (8.0.0) and replaced by Venue.media, a list of MediaItem (type photo or video, url, caption, durationSeconds), cover first. Use the first type: photo item where you used photos[0]. URLs can differ from the old ones: venues with media in Bookable's library now serve Bookable-hosted files. fields=photos becomes fields=media.
  • Availability space minimumSpend can now have several entries: one per minimum-spend band crossed by the booking (slot start to slot start + duration), in time order, each with its own spendType / spendValue / hireFeeValue. No total is returned. null when no band applies. spaceSpendType is the type of the first entry. maxMinSpend only compares the band in force at the slot start.
  • BookingArea.id is now the Bookable space id when the booking was placed on a specific space, and null when the TMS chose the area.
  • Booking.actualGuests: on Collins it almost always copies the party size, so don't read it as measured attendance there.
  • AVAIL-N-007 / AVAIL-N-008 are also returned when an operator booking_window rule closes the date. New BKRUL-N-007 (amend) and BKRUL-N-008 (cancel) refuse changes to a confirmed booking too close to its start — DELETE can now fail with BKRUL-N-008. See the Partner Booking Rules API v1.6.0 entry below and the error catalog.

[Register Webhook - v2.0.0] - 2026-10-16

Added

Register Webhook v2.0.0

  • Several webhook subscriptions per partner, each with its own callback URL, secretKey and optional eventTypes filter, so an app acting for you can subscribe without touching your own integration:
    • GET /webhooks/subscriptions — list (secrets are never returned).
    • POST /webhooks/subscriptions — create. Returns webhookId and the secretKey, shown once.
    • GET, PUT (partial update; active: false pauses deliveries), DELETE /webhooks/subscriptions/{webhookId}.
    • POST /webhooks/subscriptions/{webhookId}/secret — rotate the secret. Accept the old and new secret for a short time after rotating.
  • Every delivery now carries X-Webhook-Id (the subscription's webhookId). Each subscription signs X-API-Key with its own secretKey — use the header to pick the right one.
  • New webhook.ping event type: a test with no payload, sent only when you call POST /webhooks/test. Test deliveries carry X-Webhook-Test: true.
  • New error codes WHK-N-001 to WHK-N-007. See the error catalog.

Changed

  • BREAKING CHANGE: POST /webhooks/test is no longer deprecated and works differently. It answers 200 (was 202) with a report per subscription in deliveries[] (delivered, statusCode, responseBody, durationMs, payload, signature). A failed delivery is delivered: false, no longer a 500. It goes to every active subscription (or one, with ?webhookId=), one attempt, 10 second timeout, no retries.
    • Production sends only webhook.ping. Other event types return 422.
    • Sandbox can also send booking.updated, message.received and venue.updated, as a sample, from one of your real bookings or venues, or with simulated changes.
  • See the Webhook Guide.
  • Booking lists every field a booking.updated carries (company, location, productName, productType, notes, source, preorders, preorderMenus).
  • Limits stated: at most 10 subscriptions (409 WHK-N-004); at most 10 POST /webhooks/test calls per minute (429 RATE-R-001); a test bookingId must be your own booking (403 PMAP-N-003).

Removed

  • BREAKING CHANGE: the single-webhook endpoints POST, PUT and DELETE /webhooks are removed. Use /webhooks/subscriptions. Your existing webhook is kept as a subscription (isDefault: true).

[Handling Webhook Events - v1.9.0] - 2026-10-16

Added

Handling Webhook Events v1.9.0 (includes v1.8.0)

  • New webhook.ping event type: sent only when you call POST /webhooks/test, with no bookings, messages or venues. Test deliveries carry X-Webhook-Test: true; a real event never does. Answer 204.
  • dateTime on booking.updated bookings: the real moment the booking starts, in the venue's local time with its UTC offset. date and time stay on the venue's trading day. Left out if Bookable can't work out the real start.
  • MessagePayload now documents every field that is sent: id (use it to dedupe), subject, senderEmail, direction (always operator_to_partner), replyTo and attachments (filename, contentType; the files come by email).

Changed

  • A payment status change also fires booking.updated. Payments are not in the payload, so only lastUpdate changes. Treat it as a no-op.
  • Sandbox testing: use POST /webhooks/test to send any event type. See the Webhook Guide.
  • company on booking.updated is now the company named on the booking. It used to carry the operator's own business name. Left out when the booking has none.
  • A booking with no TMS reference yet, or with no guest name or email, is now sent with "" in reference, firstName, lastName or email. Such bookings used to fail to send at all.
  • booking.updated and message.received deliveries now time out after 45 seconds in total, retries included (was 100 seconds). An endpoint that takes longer than 45 seconds used to succeed and is now treated as failed and retried. Answer within 10 seconds, as before.
  • A 429 Retry-After is honoured up to 10 seconds.
  • Documented: the X-Webhook-Id and X-Webhook-Test headers; signing with the subscription's secretKey; retries and redelivery per event type (message.received is not redelivered automatically); empty collections and fields are left out rather than sent as null; MessagePayload.id is always present; who receives venue.updated; subscriptions with an eventTypes list receive only those types.

[Listings API - v2.0.0] - 2026-10-16

Added

Listings API v2.0.0

  • media on Space and AvailabilitySpace: the space's own photos and videos, then venue items assigned to it. Empty when it has none — use the listing's media.

Changed

  • BREAKING CHANGE: photos (a list of URLs) on listings is removed and replaced by media, a list of MediaItem (type photo or video, url, caption, durationSeconds), cover first. Use the first type: photo item where you used photos[0]. URLs can differ from the old ones (Bookable-hosted once the venue's media is in Bookable). An event_ticket listing without its own images shows its venue's.
  • AvailabilitySpacePolicies.minimumSpend can now have several entries, one per band crossed by the booking, in time order. No total is returned. spaceSpendType is the type of the first entry.
  • Calendar rule endTime: an endTime before startTime means the window ends the next day (e.g. 18:00–01:00). 00:00 means end of day.

[Partner Booking Rules API - v1.6.0] - 2026-10-16

Added

Partner Booking Rules API v1.6.0

  • New effect booking_window: you may not book, amend or cancel (params.action) within params.minHoursBefore hours of the start, or book more than params.maxHoursBefore hours ahead. Hours are real elapsed time (Europe/London). Amend and cancel windows only apply to confirmed bookings. The strictest matching rule wins. Errors: AVAIL-N-007 / AVAIL-N-008 (book), BKRUL-N-007 (amend), BKRUL-N-008 (cancel).
  • New moment booking_cancel (DELETE /venues/bookings/{bookingId}). There is no cancel hook filter: cancel rules are returned without one.
  • New effect preorder_email and consequence skips_preorder_email: below params.threshold guests the Collins pre-order email is not sent. The pre-order is still posted and the booking is never refused. New writable path and fact booking.sendPreorderEmail.
  • New params.perItem for max_quantity and max_quantity_party_size: cap each item on its own instead of the set's total.
  • New caller.categoryIdsByOperator: your partner categories for each operator that has a rule in rules[]. This is the value of the fact partner.categoryIds — read categoryIdsByOperator[String(rule.operatorId)].

Changed

  • caller.partnerCategoryIds is kept for backward compatibility but is no longer the value of partner.categoryIds. Only use it if the operator's entry is missing.
  • The fact venue.id is now the venue composite id ({operatorId}|{rmsSlug}|{venueId}), not the raw venue id. If you evaluate rules yourself, a raw id no longer matches.
  • Rule error codes can now be BKRUL-N-001 to BKRUL-N-008, BKRUL-N-100, AVAIL-N-007 or AVAIL-N-008.
  • Expression rules that target partners in when are filtered for you: a rule is only returned if it can apply to you. Returned rules can contain other partners' ids when they also apply to you.

[Messaging API - v2.0.1] - 2026-10-16

Changed

  • To test your message.received receiver, use POST /webhooks/test with eventType: message.received. It reports what your endpoint answered. The sandbox direction override answers 201 even when delivery fails, and does not deliver an identical message twice in the same hour.

[Availability Feed] - 2026-10-16

Added

  • date_time on Collins availability feed slots: the real moment the slot starts, in the venue's local time with its UTC offset. Send it unchanged as dateTime when booking. Shards written before this release don't have it until their date is regenerated. Where it is missing, use date + time.
  • New request_reason value operator_rule: an operator route_to_enquiry rule makes the slot a request. Your enquiry policy never removes these slots.
  • Operator booking_window rules for your channel apply to your feed: slots inside the minimum notice or past the horizon are left out. See Operator rules for your channel.

Changed

  • Collins slots after midnight are now published at their real time. date and time stay on the venue's trading day: a 00:30 slot in Saturday's shard starts on Sunday, and date_time says so.
  • Documented slot fields that were already sent: merchant_id, service_id, room_id, room_name and duration_requirement.

[Availability Feed] - 2026-10-08

Added

  • Per-area rooms for Zonal products with two or more areas: one slot per area, with room_id, room_name and space_id. Send space_id as spaceId to book that area. See Per-area rooms.

[Handling Webhook Events - v1.7.0] - 2026-10-06

Added

  • New venue.updated event. It is sent when a venue closes.
    • The closed venues are in the venues array. Each one has compositeId, name, active (false) and shutAt (the closing date, or null if unknown).
    • compositeId is the venue id (like in GET /venues). It is not a product compositeId.
    • You can get this event for a venue you don't sell. Ignore venues you don't know.
    • If your endpoint answers 4xx, the event is not sent again. 5xx and timeouts are retried.
  • booking.updated now includes actualGuests and actualSpend: how many guests came and how much they spent. They are filled in after the visit.

Changed

  • Your webhook handler must ignore event types it doesn't know. We will add new event types. See the Webhook Guide.

[Bookings API] - 2026-10-06

Added

  • VENUE-N-009 (404): the venue is closed. Returned by GET /venues/{compositeId}, availability, create booking and update booking. You can still cancel (DELETE) bookings at a closed venue. See the error catalog.
  • AVAIL-N-008 (400): the date is too far in the future for this product.

Changed

  • AVAIL-N-007 is now also returned when the date is too soon (the product needs more notice). Sending type: "request" does not avoid it.
  • GET /bookings/{bookingId}/messages: body now contains only the operator's text — no email template, signature or quoted replies. Automatic booking confirmations and cancellations are no longer sent as messages; you already get them as booking.updated.

Fixed

  • When a booking becomes an enquiry, the enquiry policy in the response now respects the operator's booking overrides.

[Availability Feed] - 2026-10-06

Added

  • advance_bookings_min_days / advance_bookings_max_days in availability feed index.json: the minimum and maximum number of days ahead the product can be booked. Dates outside this range are not in the feed.
  • active / shut_at in index.json: when a venue closes, active is false, shut_at is the closing date (or null if unknown) and shards is empty. If active is missing, treat it as true.

Changed

  • Dates that become too close to book are removed from the feed. Re-read index.json every day.

[Partner Booking Rules API - v1.0.0] - 2026-10-05

Added

Partner Booking Rules API v1.0.0

  • New GET /booking-rules (scope venue:read): lists the booking rules that apply to you, so you can avoid rejected bookings. Bookings are still checked by the server.
  • You only see rules that apply to you, and only for venues you can see.
  • A booking that breaks a rule fails with 400 and a code from BKRUL-N-001 to BKRUL-N-006 (see the error catalog). Some rules turn the booking into an enquiry instead.
  • Booking updates are checked against the whole booking, so an update can fail even if you only changed contact details.
  • payment rules (GET /booking-rules?hook=payment) change the amount to pay for a booking. Don't check them yourself: read the amount from GET /venues/bookings/{bookingId}/payment-options.
  • Operator accounts get 403.

[Bookings API - v7.12.0] - 2026-10-02

Added

Bookings API v7.12.0

  • GET /venues/bookings: new sortBy query parameter (new BookingSortBy enum) — date (default) orders by reservation date, then start time; createdDate orders by when Bookable received the booking (the booking's createdDate), regardless of its reservation date.
  • GET /venues/bookings: new sortDirection query parameter (new BookingSortDirection enum: ASC, DESC) — defaults to DESC (latest first), unlike /venues.

Changed

  • GET /venues/bookings: the partnerBookingId and operatorBookingId filters are now documented as partial, case-insensitive matches, in line with firstName, lastName, and email (whose descriptions now also state case-insensitivity explicitly).

[Bookings API - v7.11.0] - 2026-10-01

Added

Bookings API v7.11.0

  • GET /venues/bookings: new venueName query filter — partial, case-insensitive match on the booked venue's name. Matches the venue record regardless of its active flag, so bookings at deactivated venues are still findable.
  • Booking.venueName: new nullable field — the name of the booked venue, resolved ignoring the venue's active flag so a booking at a since-deactivated venue still reports it. null only when no venue record exists for the booking's composite. Also a valid top-level fields value on GET /venues/bookings and GET /venues/bookings/{bookingId}.
  • Booking.actualGuests: new nullable integer — the number of guests who actually attended, as reconciled by the operator's TMS after the visit. null until the TMS reports it (so normally until after the booking date, and permanently on systems that never report it). 0 is a real value meaning no-show, distinct from null.
  • Booking.actualSpend: new nullable number — the amount the party actually spent, as reconciled by the operator's TMS after the visit. null until the TMS reports it. Distinct from depositAmount (taken up front) and from any preorder pricing.

Removed

  • BREAKING CHANGE Payment links for minimum-spend policies, added in v7.10.0, are removed: paymentOptions on availability time-slot space policies, BookingRequest.paymentOptionType, and Booking.payment are gone. Minimum-spend payments remain available through the experimental Payment API (GET /venues/bookings/{bookingId}/payment-options, POST /venues/bookings/{bookingId}/payments).
  • BREAKING CHANGE AvailabilityTimeSlot.depositRequired and AvailabilityTimeSlot.paymentRule, added in v7.10.0, are removed, along with the ResolvedPaymentRule schema (common/DepositRule.yaml). Use product.depositRequired and the product's deposit rules instead.

[Register Webhook - v1.4.0] - 2026-10-01

Added

Register to Webhook Events API v1.4.0

  • Booking.actualGuests / Booking.actualSpend on the booking.updated payload: new nullable fields carrying the guest count and spend reconciled by the operator's TMS after the visit. null until the TMS reports them; actualGuests: 0 means no-show, distinct from null.
  • A change to actualGuests or actualSpend is itself a booking.updated trigger — expect a notification after the visit with no change to status.

[Bookings API - v7.10.0] - 2026-09-23

Added

Bookings API v7.10.0

  • BookingRequest.company / UpdateBookingRequest.company / Booking.company: new nullable company/business name field for a booking. When omitted, falls back to the company name configured by the operator for the requesting partner/channel, if any. Currently wired through for Collins only — other RMS integrations accept but ignore it. Shared schema (Customer) change on the Listings API side too.
  • BookingRequest.commission / UpdateBookingRequest.commission / Booking.commission: new nullable partner commission field, forwarded to Collins as commission_amount when the booking's venue runs on Collins.
  • PATCH /venues/bookings/{bookingId}: /company and /commission are now patchable JSON Patch paths.
  • Menu.fixedPrice / Menu.fixedPriceRules: new fields — whether the menu is sold at a fixed price, plus an array of FixedPriceRule fixed-price tiers (price per number of included items). New FixedPriceRule schema.
  • X-Booking-Source header: new embed value — marks a booking placed through an embedded client (e.g. the partner portal embedded in a partner's site or app).
  • Payment links for minimum-spend policies: GET /venues/{compositeId}/availability time slots now return paymentOptions (array of PaymentOption, on each space's policies) — prospective payment amounts computed from that slot's minimum spend entries, one per option type (full_minimum_spend, deposit_25_minimum_spend). Pass the chosen option's type as the new BookingRequest.paymentOptionType to obtain a payment (with paymentUrl) on the created Booking; ignored when the space requires no payment. New shared schemas PaymentOptionType, PaymentOption, PaymentStatus, Payment (common/Payment.yaml).
  • AvailabilityTimeSlot.depositRequired: new nullable boolean — true when a deposit/payment rule matched this exact slot (party size, date, time, duration), distinct from product.depositRequired which only says the product has deposit rules configured at all.
  • AvailabilityTimeSlot.paymentRule: new nullable ResolvedPaymentRule (common/DepositRule.yaml) — the single deposit/payment rule matched against this slot's actual request parameters, with amount already resolved for the request's party size (including any adult/child split). null when no rule matched.

[Listings API - v1.4.0] - 2026-09-23

Added

Listings API v1.4.0

  • Customer.company: new nullable company/business name field on the order-level customer, applied to every item in the order. When omitted, falls back to the company name configured by the operator for the requesting partner/channel, if any. Currently wired through for Collins (table_reservation) only — other platforms accept but ignore it.
  • OrderItemUpdate.company: new nullable guest company/business name field on PATCH /v1/orders/{orderId} items — applies to either capability.
  • Menu.fixedPrice / Menu.fixedPriceRules: new fields — whether the menu is sold at a fixed price, plus an array of FixedPriceRule fixed-price tiers (price per number of included items). New FixedPriceRule schema.
  • X-Booking-Source header: new embed value — marks an order placed through an embedded client (e.g. the partner portal embedded in a partner's site or app).

Changed

  • OrderItem.commission description clarified: now wired through for event_ticket (Tonic's partner_commission) and table_reservation on Collins (forwarded as commission_amount); other table_reservation RMS integrations accept but ignore it. Previously table_reservation behaviour was undefined.

[Availability Feed] - 2026-09-14

Added

  • request_reason on availability feed shard slot entries — why type is "request". Known values: fully_booked, exceeds_auto_confirm, request_only; new values may be introduced, clients should handle unknown values gracefully. Omitted when type is "book".

[Bookings API - v7.8.0] - 2026-09-08

Added

Bookings API v7.8.0

  • MinimumSpendRuleBase.spendType / MinimumSpendOverrideBase.spendType: new nullable per-rule/per-override SpaceSpendType. Two-level spend type model: the policy's spendType (MinimumSpendPolicyResponse.spendType) is the space-wide default; any rule or override may now set its own spendType to differ from that default — e.g. a Mon–Tue rule with MinimumSpend and a Wed–Sun rule with HireFeePlusMinimumSpend under the same policy. A rule/override with no spendType of its own inherits the policy's. The effective spend type for a rule/override is its own if set, else the policy's — and its spendValue/hireFeeValue must match that effective type, not necessarily the policy-level one. Shared schema (common/VenueSpaces.yaml) with the Listings API.

Changed

  • SpaceSpendType, MinimumSpendPolicyResponse.spendType, and the spendValue/hireFeeValue descriptions on rules/overrides clarified to document the two-level default/override spend-type model above.

[Listings API - v1.2.0] - 2026-09-08

Added

Listings API v1.2.0

  • MinimumSpendRuleBase.spendType / MinimumSpendOverrideBase.spendType: new nullable per-rule/per-override SpaceSpendType. Two-level spend type model: the policy's spendType (MinimumSpendPolicyResponse.spendType) is the space-wide default; any rule or override may now set its own spendType to differ from that default — e.g. a Mon–Tue rule with MinimumSpend and a Wed–Sun rule with HireFeePlusMinimumSpend under the same policy. A rule/override with no spendType of its own inherits the policy's. The effective spend type for a rule/override is its own if set, else the policy's — and its spendValue/hireFeeValue must match that effective type, not necessarily the policy-level one. Shared schema (common/VenueSpaces.yaml) with the Bookings API.
  • AvailabilitySpacePolicies.minimumSpend[].spendType: same two-level model now surfaced on the availability response itself, not just the policy-management schemas — the effective SpaceSpendType for that specific minimumSpend entry (its own if set, else the space's spaceSpendType). spendValue/hireFeeValue on the entry are populated according to this effective type.
  • GET /v1/listings — bookableProductName query parameter: filter to listings having at least one entry in bookableProducts[] whose name matches — partial, case-insensitive, with a semantic (vector similarity) fallback for near-matches on the product/ticket type name (e.g. "Sunday Roast" also surfacing "Sunday Lunch").

Changed

  • SpaceSpendType, MinimumSpendPolicyResponse.spendType, and the spendValue/hireFeeValue descriptions on rules/overrides clarified to document the two-level default/override spend-type model above.
  • GET /v1/listings query parameter venueName renamed to listingName. Also enhanced: adds a semantic (vector similarity) fallback for near-matches, and for an event listing now matches against either the event's own title or the name of the venue it's hosted at.

[Availability Feed] - 2026-09-08

Added

  • deposit object on availability feed shard slot entries (amount, currency_code, amount_per) — the product's conditional deposit rule matched against the slot's date, time, party size, and duration, mirroring paymentRules / ConditionalDepositRule elsewhere in the API. Omitted when the product has no deposit rules, or none match the slot. The Google Feed and Listings Feed jobs now share the same deposit-matching logic.

Changed

  • A generated slot whose local date/time falls in a DST spring-forward gap (a local time that never occurs) is now dropped from the feed instead of aborting generation for the whole product.

[Listings API - v1.1.0] - 2026-09-07

Added

Listings API v1.1.0

  • New GET /v1/listings/{listingId} endpoint — retrieve a single listing (venue or standalone event) by its listingId, returning the same ListingGroup shape as GET /v1/listings (groupName + items[]) but with items[] holding exactly the one match. Lets a caller that already has a listingId re-fetch it directly without paginating the whole catalogue. Requires listing:read.
  • Bookable.deposit.rules — array of ConditionalDepositRule, the full conditional deposit/payment rule schedule for a bookable unit when the RMS provides one (Collins today). Unlike deposit.rule — a single flat amount — a bookable unit may have several of these, each varying by day of week, time window, date range and/or party size (e.g. "£5 per person on Saturdays"). null/empty when the RMS does not provide conditional rules.
  • minDuration, maxDuration, durationInterval on availability entries — minimum/maximum selectable duration and step size (minutes), alongside the existing fixed duration. null when the product has no such concept.
  • duration added to both the root defaults and per-entry overrides on POST /v1/availabilities requests, mirroring the existing date/time default-inheritance pattern.
  • spaceSpendType on space policies (new SpaceSpendType enum: MinimumSpend, HireFee, HireFeePlusMinimumSpend), plus hireFeeValue alongside spendValue on minimumSpend entries — spendValue/hireFeeValue are populated according to which spend type is configured. Shared schema with the Bookings API (common/VenueSpaces.yaml).

Changed

  • Clarified ID terminology throughout the spec description: the 3-segment identifier (Listing.id) is now consistently called listingId, kept explicitly distinct from the 4-segment compositeId (Bookable.compositeId). Description text only — no schema or field changes.

[Bookings API - v7.7.0] - 2026-09-07

Added

Bookings API v7.7.0

  • paymentRules on booking type — array of ConditionalDepositRule, the full conditional deposit/payment rule schedule for a booking type when the RMS provides one (Collins today). Unlike depositRule — a single flat amount — a booking type may have several of these, each varying by day of week, time window, date range and/or party size (e.g. "£5 per person on Saturdays"). null/empty when the RMS does not provide conditional deposit rules.
  • minDuration, maxDuration, durationInterval on GET /venues/{compositeId}/availability times[] entries — minimum/maximum selectable duration and step size (minutes), alongside the existing fixed duration. null when the product has no such concept.
  • spaceSpendType on space policies in the availability response (new SpaceSpendType enum: MinimumSpend, HireFee, HireFeePlusMinimumSpend), plus hireFeeValue alongside spendValue on minimumSpend entries — spendValue/hireFeeValue are populated according to which spend type is configured. Shared schema with the Listings API (common/VenueSpaces.yaml).
  • The availability feed shard format gains the same min_duration, max_duration, duration_interval fields as the live availability response — Collins-backed products get real per-party-size bounds, other RMSs fall back to min_duration = max_duration = duration_minutes with duration_interval: null.

[Listings API - v1.0.0] - 2026-08-25

Added

Listings API v1.0.0

  • New venue-aggregated discovery API. GET /v1/listings returns the bookable catalogue grouped by operator (ListingGroup → groupName + items[]), each item a single venue (ListingItem) carrying a location and a capabilities[] array of Listings — one entry per capability (table_reservation, event_ticket). A venue that also hosts a ticketed event appears once, with two capability entries.
  • All bookable units (venue products, ticket types) are unified under a single Bookable shape in bookableProducts[]; capability-specific fields are nullable, with context set by the parent Listing.capability.
  • Temporal data (opening hours, event occurrences, blackout dates) is unified under availabilityOccurrence[] — a single CalendarRule model shared by both capabilities, discriminated by type (date_range, recurring, time_based, specific_dates, and time-window variants of each).
  • Pre-order assets (packages, menus) are unified under a single preorders container, applicable to either capability.
  • Two distinct, non-interchangeable ID formats, both CompositeId-encoded: Listing.id (3 segments — {VenueGroupId}|{RmsSlug}|{ResourceId}) vs. Bookable.compositeId (4 segments, adds {AdditionalId}), the latter used in bookableProducts[] and as compositeId in /v1/availabilities and /v1/orders.
  • POST /v1/availabilities: batch availability check across multiple compositeIds in one call. Modelled as a command, not a search — root-level date/quantity/time act as defaults inherited by each entry. Searches run independently: a failure on one compositeId is reported as an error on that entry's result only (never a 404 for the whole call); other results return normally.
  • POST /v1/orders: create an order of one or more independent bookings, each resolved and booked separately — a failure on one item does not block or roll back the others. Items are unified (no capability/oneOf); capability and platform are resolved server-side from each item's compositeId, so a single order can span multiple venues and RMS platforms.
  • PATCH /v1/orders/{orderId}: partial update of one or more bookings within an order, same per-item isolation model. Supports moving a booking to a different bookable product via compositeId (same venue/RMS/event only — cross-venue move rejected with 400 ORDER-N-007), updating guest details, and replacing (preorders) or incrementally changing (preorderChanges) pre-orders (mutually exclusive — 400 ORDER-N-008).
  • DELETE /v1/orders/{orderId}: cancel specific bookings via bookingIds, or every booking on the order when omitted.
  • Both POST /v1/orders and PATCH /v1/orders/{orderId} return 200 when every item succeeds, 207 whenever one or more items fail (including total failure) — a bulk success is never conflated with a partial or total failure.

[Messaging API - v2.0.0] - 2026-08-21

Changed

Messaging API v2.0.0

  • BREAKING CHANGE The Messaging API is now the operator↔partner conversation stored against a booking. Bookable relays each message between the venue operator and the integration partner over email (both parties email a per-booking conversation alias and Bookable forwards each message on). The previous operator→guest / IP→operator / administrator model is removed.
  • BREAKING CHANGE POST /bookings/{bookingId}/messages now returns 201 with the created Message body (previously returned 204 and processed asynchronously). Sending is synchronous: the message is stored and relayed before the response returns.
  • BREAKING CHANGE Send request body: message renamed to body; maxLength raised from 2000 to 5000.
  • BREAKING CHANGE Removed the recipient field. Send direction is now derived from the caller's role — an Integration Partner sends to the venue operator (partner_to_operator); a venue group operator sends to the integration partner (operator_to_partner).
  • New direction request field is a Sandbox-only test override: it forces the absolute direction so a partner can trigger their own message.received webhook (send operator_to_partner) without a real operator or inbound email. Ignored outside Sandbox; when set in Sandbox the email relay is skipped (webhook-only — message stored, webhook fires, no email sent).
  • Message schema changes:
    • content renamed to body.
    • action (sent/received) replaced by direction (operator_to_partner / partner_to_operator) — an absolute direction stating who sent and who received, now required.
    • Added subject (nullable) — email subject line.
    • Added attachments (nullable array of MessageAttachment with filename and nullable contentType). Attachment bytes are exchanged over email, not via this API — attachments cannot be sent through POST and can only be added by replying to the relay email.
  • New MessageAttachment schema.

[Register Webhook - v1.3.0] - 2026-08-21

Added

Register to Webhook Events API v1.3.0

  • Documented event delivery guarantees: delivery is at-least-once — the same event may arrive more than once, so consumers must be idempotent (dedupe booking events by booking id, messages by message id).
  • Documented request signing: every callback POST carries an X-API-Key header holding a lowercase hex HMAC-SHA256 of the raw body, keyed with the secretKey from registration.
  • Documented the two eventType values — booking.updated (payload in bookings) and message.received (payload in messages).
  • Added full callback payload schemas that were previously undocumented: BookingNotification, Booking, and MessagePayload.
  • MessagePayload now documents id (stable, use to deduplicate), bookingId, body, subject (nullable — primary filter signal), senderName, senderEmail, direction, attachments (metadata only; bytes over email), sentAt, and replyTo — the per-booking email alias to reply to; email it from anywhere and Bookable relays your message to the venue operator.
  • message.received fires only for operator_to_partner messages (venue operator → partner).

Deprecated

  • POST /webhooks/test is deprecated and scheduled for removal in 2.0.0. For ongoing integration testing use the sandbox self-echo flow instead — in sandbox every booking you create, amend, or cancel fires the corresponding webhook to your registered callback with no separate trigger.

[Operator Site FAQs API] - 2026-08-21

Added

Operator Site FAQs API

  • The FAQ write verbs are now public (previously x-internal). Operators can now manage a venue's FAQ list directly:
    • PUT /venues/{venueCompositeId}/site-faqs — replace the whole array (also the bulk-import mechanism for a single venue's full list). Requires venue-group:update.
    • PATCH /venues/{venueCompositeId}/site-faqs — apply an RFC 6902 JSON Patch (item-index pointers, e.g. /0/answer, or /- to append). Requires venue-group:update.
    • DELETE /venues/{venueCompositeId}/site-faqs — wipe the stored array (idempotent). Requires venue-group:delete.
    • POST /venues/site-faqs/bulk — apply changes across many venues in one all-or-nothing transaction. Requires venue-group:update.
  • GET is now readable by operators and mapped partners (previously mapped partners only). Access is enforced by the caller's venue-group ownership of, or partner mapping to, the venue.

Changed

  • SiteFaq.question and SiteFaq.answer are now nullable and no longer required.

[TMS Gateway API] - 2026-08-21

Added

  • OperatorTmsCredentials.message: new nullable string on the TMS credentials/connection response — free-text notes about the connection (e.g. a TMS-specific sync-schedule caveat). null when none.

Changed

  • VenueSpaces schema: MinimumSpendRuleResponse renamed to MinimumSpendRuleBase and MinimumSpendOverrideResponse renamed to MinimumSpendOverrideBase. The JSON shape is unchanged; only the schema component names differ (regenerate clients that reference these names).

[Availability Feed] - 2026-08-20

Changed

  • Feed window extended from 90 to 180 days.
  • Incremental refresh — previously Zonal-only — now applies to all RMS types, including Collins. On each daily regeneration, a date's shard is only rewritten when its content could actually have changed: a per-RMS activity signal (new/cancelled bookings) or a config-hash change (any slot-affecting ServicePairConfig field) marks it dirty; otherwise the previous shard is carried forward unchanged. Every date is still force-regenerated on the first run, on any config-hash change, and on a weekly full-sweep day (Monday by default) — so no date can go stale indefinitely. Shard URLs are unaffected; a carried-forward date's content may simply be up to a week old rather than always reflecting the last 24 hours.

[Bookings Api - v7.5.0] - 2026-08-12

Added

  • New endpoint PUT /venues/bookings/{bookingId}/status — confirm or reject an in-progress booking. Set status to Confirmed to accept or Rejected to decline; only bookings still awaiting a decision (Pending or InProgress) can be actioned, otherwise 422. Optional free-text reason recorded when rejecting. Requires the new venue-booking:update:status scope, granted separately and not available to all partners by default (403 if unauthorised). New UpdateBookingStatusRequest schema.
  • venue-booking:update:status: new OAuth scope (Live and Sandbox) — grants permission to confirm/reject an in-progress booking.
  • Booking.rejectionReason: new nullable field — the reason a booking was rejected, when one was provided. Null otherwise.
  • Booking.tmsCreatedDate: new nullable date-time on booking responses — creation timestamp reported by the originating TMS; null when unavailable. Also usable as a sort field on GET /venues/bookings. Booking.createdDate clarified as the timestamp the record was created in Bookable.
  • Product.categories: new nullable array of all main category slugs assigned to a product (a product may have more than one). Product.category retained as the primary (first) slug for backwards compatibility.
  • MinimumSpendOverride.timeRange: new optional Europe/London time window a minimum-spend override applies to, returned in venue space data. Absent means the override covers the whole date; outside the window normal rules apply.

Changed

  • Availability feed regeneration changed from every 4 hours to once daily. Product.feedUrl is now also null when the product is not currently reachable by any partner (previously only null when no feed had been generated yet).

[Register Webhook 1.2.0] - 2026-08-10

Added

Register to Webhook Events API v1.2.0

  • Webhooks can now be tested in the sandbox environment. Register your callback URL against https://api-sandbox.bookabletech.com and any booking you create, amend, or cancel via the sandbox API delivers a signed notification to your endpoint — the same payload and X-API-Key HMAC-SHA256 signature as production, with no external reservation system required. The sandbox server was added to the Register to Webhook Events API. See the Webhook Guide.

[7.3.0] - 2026-07-09

Changed

BookingApi v7.3.0

  • Action required Availability feed format: the single 90-day gzip file per product is replaced by a plain-JSON index.json plus one gzip-compressed daily shard file ({date}.json.gz) per day with availability. The previous {productId}.json.gz files are no longer generated, so feed consumers need to update their download logic to the new format.
    • Product.feedUrl now points to the index (.../{productId}/index.json). It is plain JSON — do not decompress it.
    • The index lists shards[], one entry per non-empty day, each with date and a direct url to that day's gzip-compressed shard. Days with no availability are omitted.
    • Each shard contains product_id, date, and the slots array. The slot object shape is unchanged. product_name and venue_name now appear only in the index.
    • Partners can download only the dates they need instead of the full 90-day payload. See the Availability Feed guide for the new format and migration notes.

[Webhook 1.5.0] - 2026-07-08

Changed

Handling Webhook Events API v1.5.0

  • BREAKING CHANGE ReservationStatus enum updated to mirror the Bookings API booking statuses (Pending, InProgress, Confirmed, Cancelled, Deleted, Lost):
    • Added: in_progress (enquiry received and assigned but not yet confirmed), deleted (booking deleted from the system), lost (booking not completed before its scheduled date).
    • Removed: completed, no_show. Update any handling logic that depends on these values.

[7.2.3] - 2026-07-02

Added

BookingApi v7.2.3

  • Product.sub_category: new nullable string field — admin-defined sub-category slug (e.g. "outdoor", "easter", "christmas"). null when no sub-category applies.
  • noAvailabilityCode: two new known values:
    • NO_AVAILABLE_TIMES — RMS confirmed the request was valid but returned no bookable time slots.
    • FILTERED_BY_CAPACITY_MIN — party size is below the minimum capacity of every available space.
  • RecurringRuleData and RecurringWithTimeRuleData: daysOfWeek and months are no longer individually required; either may be provided alone (when both are present the match is AND). Both fields are now nullable with no minItems constraint.

Messaging API v1.0.0

  • New API spec at apis/production/MessagingApi.yml for sending and retrieving messages associated with a booking.
  • POST /bookings/{bookingId}/messages — send a plain-text message (async, returns 204). Direction determined by caller role:
    • Integration Partner → message delivered to venue operator. recipient field ignored.
    • Operator → message delivered to booking guest. recipient field ignored.
    • Administrator → recipient field required (guest or venue).
  • GET /bookings/{bookingId}/messages — list all processed messages for a booking, ordered by sentAt ascending. Page-based pagination via pageNumber and pageSize (default 20, max 100).
  • Required scopes: venue-booking:messaging:write (send), venue-booking:messaging:read (list).

Handling Webhook Events API v1.4.0

  • New message.received event type: fires when a venue operator sends a message via their TMS.
  • New messages array field on BookingNotification: populated for message.received events, null for booking.updated.
  • New MessagePayload schema: bookingId, content, senderName (nullable), sentAt.

[7.2.0] - 2026-06-10

Added

  • Product.feedUrl: new nullable URI field on GET /venues and GET /venues/{venueId} responses. When non-null, provides a direct URL to the pre-generated availability feed file for that product — a gzip-compressed JSON document covering a 90-day rolling window, regenerated every 4 hours. No authentication is required to download it.

[7.1.0] - 2026-05-06

Added

  • X-Is-Cross-Sale header on POST /venues/{compositeId}/booking: optional boolean. When true, any cross-sale booking label rules configured for the operator are applied automatically to the new booking.

[7.0.0] - 2026-04-17

Changed

  • BREAKING CHANGE BookingRequest.areaId renamed to BookingRequest.spaceId. Type changed from string to integer. Obtain valid space IDs from the spaces array in the availability response time slots.

Removed

  • AvailabilityTimeSlot.areas: removed. Use spaces from the product data to obtain valid space IDs for booking.

[6.4.0] - 2026-04-15

Added

  • AvailabilityResponse.noAvailabilityCode: new nullable string field, populated only when times is empty. Machine-readable code indicating why no availability was found. Known values:
    • NO_AVAILABILITY — no available slots for the requested parameters.
    • NO_ELIGIBLE_PRODUCTS — no products match the request.
    • FILTERED_BY_OPERATOR_RULES — all slots were filtered out by operator availability rules.
    • FILTERED_BY_CAPACITY — no slots satisfy the requested party size.
    • Clients should treat unknown values as a generic no-availability condition, as new values may be introduced without prior notice.

Removed

  • AvailabilityResponse.noAvailabilityAction: removed. Use noAvailabilityReason (human-readable) and the new noAvailabilityCode (machine-readable) instead.

[6.3.0] - 2026-04-14

Added

  • AvailabilityTimeSlot.requestReason: new nullable string field, present only when type is request. Indicates why the time slot requires manual operator approval rather than instant confirmation. Possible values:
    • fully_booked — no real-time availability for this slot, but the operator is open to receiving enquiries.
    • exceeds_auto_confirm — availability exists but the requested party size exceeds the venue's auto-confirm threshold and requires explicit operator approval.
    • Clients should handle unknown values gracefully as new values may be introduced in future versions.
  • AvailabilityResponse.noAvailabilityReason: new nullable string field, populated only when times is empty. Human-readable message explaining why no availability was found for the requested parameters.
  • Product.slug: new nullable string field — aggregation slug identifier for the product.
  • PreorderPackage.slug: new nullable string field — aggregation slug identifier for the package.
  • Menu.slug: new nullable string field — aggregation slug identifier for the menu.

[6.2.0] - 2026-04-01

Added

  • Product.spaces: new field on GET /venues and GET /venues/{venueId} responses. Each product now returns the list of spaces available within it, including physical data (spaceName, description, floorLocation, facilities, capacity layout fields) and space policies (minimumSpend, occasionTypes, under18s, promotedEvents, accessibility, servesFood).
  • Product.preOrderRequiredType: enum specifying which type of preorder is required — none, package, menu, or packageAndMenu.
  • Product.depositRequired: boolean indicating whether a deposit is required when booking a product.
  • AvailabilityRequest.children: optional field for the number of children in the party. Note: not all TMS providers distinguish between adults and children — when unsupported, children may be added to the total party size or ignored.
  • AvailabilityRequest space policy filters — new optional query parameters to filter time slots by space policy:
    • minimumSpend: maximum minimum spend (in pence); excludes slots above this threshold.
    • under18s: soft filter on the under-18s policy.
    • occasionTypes: filter by supported occasion type.
    • promotedEvents: soft filter on the promoted-events policy.
    • accessibility: filter by wheelchair accessibility.
    • servesFood: soft filter on the serves-food policy.
    • includeUnavailable: when true, filtered-out slots are included in the response with unavailableReasons populated instead of being excluded.
  • AvailabilityTimeSlot.product: new object returned in each time slot containing the product's id, name, and spaces array. Space policies within this object (including minimumSpend) are pre-filtered to the requested date and time slot.
  • AvailabilityTimeSlot.areas: list of available areas/zones for this time slot. Populated only for TMS providers that support area-based booking (e.g. Zonal). Pass the desired id as areaId when creating a booking.
  • AvailabilityTimeSlot.unavailableReasons: present only when includeUnavailable=true; contains human-readable explanations for each failing policy filter.
  • BookingRequest.children: optional field for the number of children included in the booking.
  • BookingRequest.areaId: optional area/zone ID to target when creating a booking. Obtain valid IDs from AvailabilityTimeSlot.areas.
  • Booking.depositAmount: deposit amount (float, in pence) captured from the TMS at reservation time.
  • Booking.area: area or zone assigned to the booking, with id and name as reported by the TMS.
  • New schemas: SpaceCapacityRange, Area, BookingArea.
  • New shared component files: common/VenueSpaces.yaml (space schemas and policy types) and common/Headers.yaml (shared header parameter definitions).

Changed

  • AvailabilityRequest.partySize and BookingRequest.partySize: description clarified from "number of guests/people" to "number of adults".
  • CorrelationID and PartnerReference header parameters refactored to reference common/Headers.yaml instead of being defined inline.

Deprecated

  • AvailabilityTimeSlot.productId: use AvailabilityTimeSlot.product.id instead.

[6.1.0] - 2026-03-13

Added

  • Sparse fieldsets support via the fields query parameter on all GET endpoints. Request only the fields you need to reduce payload size and improve response times. See Sparse Fieldsets for details.
  • text/toon response format support across all Bookings API endpoints that return a body. Set Accept: text/toon to receive responses in TOON (Terse Object-Oriented Notation) — a compact format that reduces token count by 30–60% compared to JSON. Fully opt-in; omitting the header continues to return standard JSON. See TOON Format for details.
  • VenuePreorders: added preorders field to GET /venues and GET /venues/{venueId} responses.

[6.0.0] - 2026-02-26

Added

  • VenuePreorders schema: new wrapper object containing packages and menus arrays
  • ProductAvailabilityRules schema: availability rules for a product grouped by source (weekly, exceptions, rules)
  • WeeklyRule schema: weekly booking schedule, one entry per day of the week
  • RuleException schema: date-specific availability exceptions imposed by the TMS
  • AvailabilityRule schema: operator-defined availability rules per partner
  • AvailabilityRuleType enum: date_range, recurring, time_based, specific_dates, specific_dates_with_time, date_range_with_time, recurring_with_time
  • RuleDataBase and all discriminated subtypes: DateRangeRuleData, RecurringRuleData, TimeBasedRuleData, SpecificDatesRuleData, SpecificDatesWithTimeRuleData, DateRangeWithTimeRuleData, RecurringWithTimeRuleData
  • PreorderContainer schema: container for all preorder items (packages → PreorderPackageRequest, menus → PreorderMenuRequestV2)
  • MenuItemOption schema: configurable option for a menu item (field value)
  • MenuItem: added fields name, price, description, diet_types, allergens, configurable_options, type, subType, displayOrder
  • MenuItemSelection: added field options (array of MenuItemOption)
  • Booking.preorders.menus: added field submitted (enum: pre / post)
  • PATCH /venues/bookings/{bookingId}: new endpoint for partial booking updates via JSON Patch (RFC 6902)
  • JsonPatchOperation schema supporting add, remove, replace operations
  • Product: added field preOrderRequired (boolean)

Changed

  • MenuItem.subGroupName renamed to subType
  • POST /venues/{compositeId}/booking response 201: changed from BookingResponse to full Booking schema
  • Terminology updated throughout: "RMS (Restaurant Management System)" → "TMS (Table Management System)"
  • Security schemes consolidated: staging environments (Staging, SandboxStaging, SandboxProduction) removed; only Production and Sandbox remain
  • Servers list reduced to Production (https://api.bookabletech.com) and Sandbox (https://api-sandbox.bookabletech.com)

Removed

  • Venue.packages (top-level array) — replaced by Venue.preorders.packages
  • Venue.menus (top-level array) — replaced by Venue.preorders.menus
  • BookingRequest.preorderPackages — replaced by BookingRequest.preorders.packages
  • BookingRequest.preorderMenus — replaced by BookingRequest.preorders.menus
  • Sandbox Staging server https://api-sandbox-staging.bookabletech.com

[5.1.0] - 2026-02-09

Added

  • compositeId query filter to the GET /venues/bookings endpoint.

[5.0.0] - 2026-01-27

Changed

BREAKING CHANGE in the following endpoints:

  • GET /venues/bookings

  • GET /venues/bookings/{bookingId}

  • PUT /venues/bookings/{bookingId}

  • Changed:

    • company field is now venueGroupName
    • productType field is now productName

  • Removed:

    • cursor query parameter from GET /venues/bookings
    • cursor field from response from GET /venues/bookings

  • Added: Standard pagination parameters in GET /venues/bookings:

    • pageNumber (integer, default: 1, min: 1) - The page index to return
    • pageSize (integer, default: 20, min: 1, max: 100) - Items per pageNumber
    • meta object with pagination metadata:
    "meta": {
      "currentPage": 1,
      "pageSize": 20,
      "totalItems": 26,
      "totalPages": 2
  }

  • Migration Guide:

      - GET /venues/bookings?cursor=abc123
  + GET /venues/bookings?pageNumber=1&pageSize=20

  • GET /venues/{compositeId}/availability

  • Added: preOrderItems

[4.12.0] - 2026-01-19

Added

  • venueGroupName field on venue object in GET /venues and GET /venues/{venueId} endpoints.

[4.11.1] - 2026-01-13

Changed

  • Remove constraints on bookingRules.

[4.10.0] - 2025-12-05

Changed

  • X-Booking-Source header in POST venues/bookings is now an enumeration.

[4.9.0] - 2025-12-03

Added

  • Added sorting capabilities to GET /venues endpoint:

    New Query Parameters

    • sortBy (optional): Field to sort results by
      • default - Sort by composite ID (venue_group_id, rms_id, venue_id)
      • name - Sort alphabetically by venue name
      • city - Sort by city name, then venue name
      • area - Sort by area, then venue name
      • venueGroup - Sort by venue group name (requires venueGroupName filter)
      • relevance - Sort by semantic similarity using vector embeddings (requires embedding filters)
    • sortDirection (optional): Sort direction
      • ASC - Ascending (A-Z, 0-9, most to least similar)
      • DESC - Descending (Z-A, 9-0, least to most similar)

[4.8.0] - 2025-12-01

Added

  • Operator Booking Id and Partner Booking Id support to GET venues/bookings by operatorBookingId and partnerBookingId fields
  • Partner Booking Id support to POST venues/bookings bypartnerBookingId field

Changed

  • Reference field is deprecated in GET venues/bookings ; use operatorBookingId instead.

[4.7.0] - 2025-10-13

Added

  • Booking Overrides support to GET venues and GET venues\{venueId} by bookingOverrides field
  • Operator availability rule support to GET venues and GET venues\{venueId} by operatorAvailabilityRules field

[4.6.0] - 2025-10-13

Added

  • Preorders support to GET venues/bookings by preorders field
  • Preorder menus support to GET venues/bookings by preorderMenus field

[4.5.0] - 2025-09-29

Added

  • Possibility to filter by date and time within the GET /venues endpoint.

[4.4.0] - 2025-09-26

Added

  • X-Booking-Source header which identifies the source or channel through which the booking was created.

[4.3.0] - 2025-09-22

Added

  • X-Partner-Reference header is now mandatory on all the endpoints for Bookable Agent clients.

[4.2.0] - 2025-09-15

Added

  • noAvailabilityAction support to GET venues/:venueId/availability
  • autoConfirmRule support to GET venues/:venueId/availability

[4.1.0] - 2025-09-08

Added

  • Preorder menu support to GET venues and GET venues/:venueId by menus field
  • Preorder menu support to POST venues/:venueId/booking by preorderMenus field
  • Preorder menu email triggering on submit booking
  • Preorder menu support to GET venues/bookings/:bookingId by preorderMenus field

Removed

  • packageId field on POST venues/:venueId/booking request

[4.0.0] - 2025-09-02

Added

  • BREAKING CHANGE: Booking PUT request now requires compositeId

Removed

  • GET /venues/products/{compositeId} endpoint

[3.4.0] - 2025-08-20

Added

  • Venue packages detail by packages
  • Booking POST request now accepts packageId
  • Booking POST request now accepts preorders

[3.3.0] - 2025-08-13

Added

  • Endpoint to get a venue product detail by compositeId

[3.2.0] - 2025-08-12

Changed

  • Venue Schema Fields: Deprecated is_active and created_at fields in venue responses
  • Booking POST request now accepts null value for duration field

[3.1.0] - 2025-07-30

Added

  • Booking POST request includes admin_notes, comments & labels field

[3.0.0] - 2025-07-29

Added

  • Standardized error handling across all endpoints

Changed

  • BREAKING CHANGE: Modified venue composition - products are now contained within the venue structure

[2.3.0] - 2025-07-02

Added

  • X-Partner-Reference header for Bookable Agents. The header specifies the partner reference for whom the booking is being made.

[2.2.0] - 2025-06-06

Added

  • Endpoint to update an existing booking by its unique ID
  • Endpoint to cancel a booking by its unique ID

[2.1.0] - 2025-05-30

Added

  • Endpoint to retrieve a paginated list of bookings
  • Endpoint to retrieve a specific booking by its unique ID

[2.0.0] - 2025-05-16

Added

  • Support for paginated venue listings

Changed

  • Rename shut into bookingCutoff

[1.2.0] - 2025-05-14

Added

  • bookingRules: Insert booking rules on Venue to show information about the opening/ close time, max min number of people, and other

[1.1.1] - 2025-05-08

Fixed

  • Validation on require field (#TS-948)

[1.1.0] - 2025-05-02

Unified API

  • Add the unified api

Added

  • VenueId: Introduced the concept of composite Id to manage id into the system
  • type into avalability response: Specifies how an operators time slot can be handled.
  • type into revervation request
  • product_name: the name of product offer from venue
 
Next page