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.

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

Deploy on production

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

Deploy on production

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

Deploy on production

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

Deploy on production

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

Deploy on production

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

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

Deploy on production

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