# Changelog This is the changelog of the Understory API. All additions or changes to API endpoints, general usage updates, and behavior changes will be reflected below. Breaking changes will be high-lighted in line with our [Breaking Changes](/docs/about/breaking-changes) policy and the affected APIs grace period will be noted. See [API Versioning](/docs/about/api-versioning) to learn more. #### 2026-10-02 **Orders API** - Added the `INTEGRATION` transaction provider to order transactions. `INTEGRATION` indicates the booking came through a reseller integration, and the reseller collected the payment. These transactions were previously returned as `UNKNOWN`. #### 2026-10-01 **Experiences API** The content blocks endpoint is labelled `Alpha`. See [API Versioning](/docs/about/api-versioning). - Added [Get content blocks](/apis/experience/getcontentblocksforexperience) under `GET /v1/experiences/{experienceId}/content-blocks`. It returns an experience's content blocks in the order Understory's own storefront presents them, in the language negotiated via `Accept-Language`, and is guarded by `experience.read`. - A content block's `type` says how it is structured, and its `handle` says what it is about. `TEXT` carries Markdown `text` and a `WHATS_INCLUDED` or `NICE_TO_KNOW` handle. `STEP_LIST` carries an optional `title`, ordered `steps` with a `title`, `description` and `image`, and an `ITINERARY` handle. Blocks without content are omitted. - Both the block `type` and the `handle` are extensible: new values are added without a new API version. Integrations must not fail on values they do not recognise. **Breaking Changes policy** - Documented that new values may be added to polymorphic types and enums marked as extensible, and that integrations must not fail on values they do not recognise. See [Breaking Changes](/docs/about/breaking-changes). #### 2026-09-28 **Bookings API** - **Breaking change:** [Create Booking](/apis/booking/createbooking) now requires `name` on a `COMPANY` customer, and answers `400` without it. The endpoint is `Alpha`, so there is no grace period. - Fixed [Create Booking](/apis/booking/createbooking) answering `500` instead of `409` with `EVENT_PAST_CUTOFF` after the booking cutoff. - Added the `409` codes `EVENT_NOT_ACTIVE`, `NOT_ENOUGH_RESOURCES` and `EVENT_EXCLUSIVITY_LOCKED` to [Create Booking](/apis/booking/createbooking). #### 2026-09-24 **Marketing API** - A marketing consent's `id` is now documented as a plain string rather than a UUID; the API never enforced the UUID format. **No response changed.** It only affects you if you generate a typed client from the OpenAPI description or validate `id` as a UUID; treat it as an opaque string. See [Get marketing consents](/apis/marketing/getmarketingconsents). #### 2026-09-21 **Availability API** - [Get Availabilities](/apis/availability/getavailabilitiesforexperience) and [Get Availability](/apis/availability/getavailabilitybyid) are now `POST` rather than `GET`. Both are still reads with no side effects; the query moves into the request body so it can carry richer context later. - `from`, `to`, `cursor` and `limit` move into that body, unchanged. The body is optional. [Get Availability](/apis/availability/getavailabilitybyid) takes none yet. - Added a `filter` object with `event_ids`, `location_ids` and `durations` (ISO 8601, e.g. `PT1H30M`). #### 2026-09-18 **Availability API** A new API for reading when an experience can be booked. It supersedes [Event Availability](/apis/event-availability/geteventavailability), which only ever described events: an experience selling timeslots across its operating hours had no availability to read at all. Both answer for the same experiences until Event Availability is deprecated on its own notice. The endpoints are labelled `Preview`: the specification is published for feedback, and they cannot be called yet. See [API Versioning](/docs/about/api-versioning). - Added [Get Availabilities](/apis/availability/getavailabilitiesforexperience) and [Get Availability](/apis/availability/getavailabilitybyid), under `/v1/experiences/{experienceId}/availabilities`. The list is windowed with `from` and `to`, and paginated on `next`. - An availability's `subject` is either `EVENT`, carrying `event_id` and the `session_id` of the sitting on show, or `TIMESLOT`, which has no event until someone books it. Both are addressed by an opaque `id` and carry `start_time`, `end_time` and `timezone`, named as on [Session](/apis/event/getevents). - `TICKET_LIMIT` reports each ticket variant and add-on separately, in `ticket_variants` and `addon_variants`, rather than the single smallest count Event Availability returns. Two variants can be limited by different resources, so one being exhausted says nothing about the other. - Added the `EXCLUSIVITY` constraint: an exclusively booked event keeps reporting its remaining seats while being unbookable to everyone but the booking that claimed it. - `available` answers whether anything can still be sold, not whether a particular basket fits. Booking creation remains the authoritative check. - Timeslots are not bookable yet through the public API. [Create Booking](/apis/booking/createbooking) names an event, and a timeslot has none until someone books it. - Guarded by `experience.read`, the scope that already covers reading experiences, so an integration that reads experiences needs no new grant. **Event Availability API** Renamed the constraint schemas so the new Availability API can use the unprefixed names. **No request or response changed.** It only affects you if you generate a typed client from the OpenAPI description, whose type names change on your next regeneration. **Orders API** - Added `provider` to a refund, mirroring the `provider` on a transaction. A refund now says where the money went without being read against the transaction it was taken from. - Values are `UNDERSTORY_PAY`, `STRIPE`, `PAYPAL`, `QUICKPAY`, `GIFTCARD`, `PUNCHCARD`, `SETTLEMENT` and `UNKNOWN`. There is no `EXTERNAL`; a payment Understory never held cannot be given back through it. - Added `PUNCHCARD` to the transaction provider. A punch card redemption is its own payment method rather than a gift card, and now says so on the paying side as well as on a refund. #### 2026-09-17 **Accounting API** The Accounting API has moved from `Preview` to `Alpha`. It is now available in production and can be integrated against. - [List journal entries](/apis/accounting/listjournalentries), [Get journal entry](/apis/accounting/getjournalentrybyid), and [Record journal entry activity](/apis/accounting/recordjournalentryactivity) now carry the `Alpha` label instead of `Preview`. - The specification is unchanged; no endpoints, fields, or behaviour differ from what the preview described. See [API Versioning](/docs/about/api-versioning) for what each label means. #### 2026-09-14 **Orders API** When a booking is refunded as a gift card, the gift card gets its own order. Neither end of that said so: a refund paid out as a gift card read identically to one returned to the guest's card, and the new order's transaction left you parsing an identifier to find where the money came from. Both now say it. - Added the `SETTLEMENT` transaction provider. It means a refund on another order was used to fund this order. - Added `SettlementTransactionDetails` to the `details` of a transaction, carrying `origin_order_id`. It names the order that was refunded, so you can trace a gift card back to the booking it replaced. - Added `details` to a refund, mirroring the `details` already on a transaction. A refund with no `details` was returned to the payment method it was taken from. - Added `SettlementRefundDetails`, carrying `destination_order_id`. It names the order created to carry the gift card, which is where you read the card itself from. #### 2026-09-07 **Accounting API** - Added the optional `detail_code` field to an activity, on both [Record journal entry activity](/apis/accounting/recordjournalentryactivity) and the activities returned with a journal entry. It classifies a failed sync so you can act on it without parsing `detail`, and so it can be shown in the reader's own language. - `detail` is unchanged and still carries what the accounting provider itself said about the posting — their wording, written for an accountant. `detail_code` says what *kind* of failure it was; prefer it, and fall back to `detail` when it is absent. - The field is omitted when the integration has nothing to classify: a successful sync, or an activity recorded before the field existed. Existing activities are unaffected. - Values are `CONFIGURATION_INCOMPLETE`, `CONFIGURATION_INVALID`, `CONNECTION_REJECTED`, `ACCESS_DENIED`, `SALES_DOCUMENT_MISSING`, `FINANCIAL_YEAR_MISSING`, `PROVIDER_REJECTED` and `UNKNOWN`. The set grows over time; treat an unrecognised value as `UNKNOWN`. #### 2026-08-26 **Accounting API** Documented whether a posting `amount` includes VAT. This is a clarification of behaviour that has always been in place — no field changed and no response is different — but the spec never stated it, and it is not what a `vat_rate` on every posting suggests. - A posting's `amount` is **gross** (VAT-inclusive) on `SALE` and `REFUND` entries, and **net** (VAT-exclusive) on `REVENUE_RECOGNITION` and `REVENUE_RECOGNITION_REVERSAL` entries. `BREAKAGE` and `ADJUSTMENT` entries carry no VAT. - Both gross and net postings state a `vat_rate`. On a net posting the rate identifies which per-rate revenue account the amount belongs to and what VAT that revenue attracts; it is not embedded in the amount. - Which of the two applies is decided by the entry's `kind`, not by the posting `type`. `BOOKING_PREPAYMENT` is gross on a `SALE` and net on a `REVENUE_RECOGNITION`, so a rule keyed on posting type cannot express it. - **If you extract VAT from every posting that carries a rate, your recognition entries are being stripped twice.** That understates recognised revenue and under-draws the prepayment by the embedded VAT, and the shortfall accumulates. The VAT account still nets to zero within the entry, so a VAT return will not surface it. - Each entry variant now states gross or net in its own description, alongside the rules on `amount` and `vat_rate`. **Bookings API** - Added the `status` query parameter to [Get bookings](/apis/booking/getbookings). Pass `ACTIVE`, `CANCELLED`, `MOVED`, or `CHECKED_IN` to return only bookings with that status, or comma-separate several to match any of them: `status=MOVED,CANCELLED`. - `PROCESSING` and `UNKNOWN` cannot be filtered on. The first is a transient checkout state and the second a defensive default, so neither is a stable thing to select by. Both still appear on returned bookings. #### 2026-08-25 **Accounting API** - Added the `BOOKING_FEE_REVENUE` posting type. It carries the booking fee a host charges the guest on top of the ticket, and appears on `SALE` and `REFUND` journal entries for orders where that fee is passed on. - The fee is earned when the booking is made rather than when the experience is delivered, so it is booked as revenue at capture and never appears on `BOOKING_PREPAYMENT`. It is not released again by a later `REVENUE_RECOGNITION` entry. - `BOOKING_FEE_REVENUE` is a booking posting: it carries the `booking` object with `experience_id` and `location_ids`, alongside `BOOKING_PREPAYMENT` and `BOOKING_REVENUE`. - The `amount` is VAT-inclusive and `vat_rate` states the fee's own rate, which need not match the rate on any ticket in the order. #### 2026-08-24 **Orders API** An order's customer may now omit their address. The Orders API is read-only, so nothing you send changes. - Updated `address` on an order's customer to be optional. It is omitted when the order has no address, where previously it was always present and filled with empty strings. - Updated `address_lines` to allow an empty list, for an address recorded without a street address. A generated client that validated the previous minimum of one entry could not decode such an order at all. - If you read the address from [Get orders](/apis/order/getorders) or [Get order](/apis/order/getorder), handle its absence. Clients that assumed the field was always present need updating, even though nothing was renamed or removed. **Bookings API** A returned booking may now omit the customer's address. Only responses changed — creating a booking works exactly as before. - Updated `address` on a returned booking's customer to be optional. It is omitted when the booking has no address, where previously it was always present and filled with empty strings. - Updated `address_lines` to allow an empty list on a returned booking, for an address recorded without a street address. A generated client that validated the previous minimum of one entry could not decode such a booking at all. - `POST /v1/bookings` is unchanged. It still requires `address` with at least one entry in `address_lines`, so no request that worked before will start failing. - If you read the address from [Get booking](/apis/booking/getbooking) or [Get bookings](/apis/booking/getbookings), handle its absence. Clients that assumed the field was always present need updating, even though nothing was renamed or removed. #### 2026-08-17 **Location API** New read-only API for resolving the `location_id` that every event session already carries. - Added [Get Locations](/apis/location/getlocations) (`GET /v1/locations`) to list the locations a company runs its experiences from, paginated with the `cursor` and `limit` query parameters. - Added [Get Location](/apis/location/getlocationbyid) (`GET /v1/locations/{locationId}`) to retrieve a single location by the `location_id` returned on a session. - A `Location` carries `id`, `timezone`, `address`, `coordinates`, `created_at`, and `updated_at`. Locations are read-only through this API; they are created and maintained by the company inside Understory. - No company-authored label is exposed. A location's name in Understory is internal to the company's own staff, so compose your own display string from the parts in `address`. - Documented that `timezone` is the authority for interpreting a session's `start_time` and `end_time`, which are returned without a UTC offset, and that it falls back to `Europe/Copenhagen` when the company has not set one. - `coordinates` is omitted unless both a latitude and a longitude are known for the location. - A location that has been removed in Understory returns `404`, so a `location_id` read from an older event or booking may stop resolving. - Added the `location.read` scope, required by both endpoints. Existing credentials do not gain it automatically — update or re-issue your credentials to request it. #### 2026-08-12 **Gift Card API** The Gift Card API is no longer read-only. - Added `POST /v1/gift-cards/{giftCardId}/extend-expiry` to push an active gift card's expiry date further out. The endpoint returns the updated gift card. It changes only the expiry date; a gift card's balance cannot be changed through this API. - The new expiry must be later than the gift card's current expiry — this action extends the expiry date and never brings it forward. An earlier or past date returns `400`. - Only gift cards with status `ACTIVE` can be extended. `EXPIRED`, `SPENT`, and `VOIDED` gift cards return `409`. - Re-sending a gift card's current expiry date has no effect and returns the gift card unchanged, so a retried request is safe. - Added the `gift-card.write` scope, required by this endpoint. Existing credentials do not gain it automatically — update or re-issue your credentials to request it. #### 2026-07-09 **Checkout deep linking guide** Added a new [Checkout deep linking](/docs/website-integration/checkout-deep-linking) guide documenting how to link visitors directly into a Storefront's checkout flow from emails, websites, and third-party listings. - Documented the checkout entry URL, `https://{storefront}.understory.io/checkout/{experienceId}`, which works identically on storefronts served from a custom domain. - Documented the stable, public deep link parameters: `eventId`, `from`, `variant/{variantId}`, and `addon/{addOnId}`, including validation behavior where invalid values are silently discarded. - Documented common patterns for linking to a specific event, a specific date, or straight to the booking & payment step, and how to build links from ids returned by the [Events](/apis/event/getevents), [Experiences](/apis/experience/getexperiences), and [Get ticket variants](/apis/experience/getticketvariantsforexperience) endpoints. These changes affect documentation only; no API behavior, schemas, or field names changed. #### 2026-06-24 **Accounting API** New APIs for consuming and reporting on journal entries in preview. This allows you to build custom accounting integrations and report back syncronization status and other relevant information to show inside Understory. Journal entries expose the postings, references, and supporting documents needed to sync financial events into external accounting and bookkeeping systems. - Added `GET /v1/accounting-journal-entries/{journalEntryId}` to retrieve a journal entry by ID. - Added `POST /v1/accounting-journal-entries/{journalEntryId}/activities` so integrations can relay how an entry was processed in an external accounting system eg. sync started, succeeded, or failed. - Added `v1.journal_entry.created` webhook event for discovery. - Added `v1.journal_entry.document_attached` webhook event, sent when a supporting document (such as a customer receipt or credit note) is attached to an existing journal entry. #### 2026-06-15 **Events API & Event Availability API** - Increased the maximum number of sessions per event from 10 to 50. The `sessions` array on `Event` now accepts up to 50 items. - Changed the `from`/`to` filters on [Get events](/apis/event/getevents) and [List Event Availability](/apis/event-availability/listeventavailability) to match against every session of an event instead of only the first. An event is now returned when any of its sessions starts within the requested window, so multi-session events remain in results while later sessions are still upcoming. - Documented the ordering of `GET /v1/events`: results are ordered by session start time, and a multi-session event appears once, positioned by its earliest session in the requested window. **Experiences API** - Breaking change: removed the `type` field from `Experience`, which previously indicated the booking model (`SINGLE_SESSION` or `MULTI_SESSION`). The Experiences API is in Alpha and not subject to the [Breaking Changes](/docs/about/breaking-changes) policy. #### 2026-05-22 **Pagination guide rewritten** The [Pagination](/docs/usage/pagination) guide has been rewritten to document the consistency model of listing endpoints and how to integrate against it. - Clarified that listing endpoints such as `GET /v1/events` and `GET /v1/bookings` are designed for ad-hoc reads, not as a continuous synchronization mechanism. - Documented that paginated responses are best-effort traversals rather than snapshots: identical requests can return different totals, and `next` does not guarantee consistency across pages. - Documented that cursors are opaque and short-lived, and must not be persisted across jobs, sessions, queues, or workflow state. - Pointed at webhooks as the right mechanism for keeping a local data store in sync. These changes affect documentation only; no API behavior, schemas, or field names changed. #### 2026-05-01 **Documentation improvements across all APIs** API reference documentation has been enriched across the Bookings, Events, Event Availability, Experiences, Gift Card, Marketing, Orders, and Webhooks APIs. Endpoint behavior, request and response semantics, and the full list of enum values are now described in line with each property. - Added or expanded `info` and tag descriptions to clarify what each API is for and how it relates to the others. - Documented the meaning of every value in lifecycle and status enums, including `Booking.status`, `Event.state`, `Event.visibility`, `Experience.state`, `Experience.type`, `GiftCard.status`, `Order.status`, `TransactionStatus`, `TransactionProvider`, `RefundStatus`, `Ticket.status`, ticket check-in `method`, line item `product_type`, information request `scope`, and webhook subscription `state`. - Clarified the semantics of `from`/`to` filters on `GET /v1/events` (matched against the first session's local start time) and the local-time-without-offset representation used by `Session.start_time`/`end_time`. - Documented the snapshot semantics and per-constraint behavior of the Event Availability response, including the `EventStateConstraint`, `EventSeatsLimitConstraint`, `BookingLimitConstraint`, `BookingCutoffTimeConstraint`, and `TicketLimitConstraint` shapes. - Standardized pagination, error, and 4xx response documentation across all specs. These changes affect documentation only; no API behavior, schemas, or field names changed. #### 2026-04-29 **Bookings API** - Added `event_id` query parameter to `GET /v1/bookings` to filter bookings for a specific event. #### 2026-04-28 **Bookings API** - Added `GET /v1/bookings/{bookingId}/information-request-answers` endpoint to retrieve answers to information requests for a booking. #### 2026-04-27 **Bookings API** - Added `EXTERNAL` check-in method to ticket check-in enum. This indicates a ticket was checked in via an external system integrated with the backoffice. #### 2026-04-10 **Marketing API** - Added `GET /v1/marketing-consents/{id}` endpoint to fetch a single marketing consent by ID. Useful for fetching consent details after receiving a webhook event. See [Get marketing consent by ID](/apis/marketing/getmarketingconsentbyid) for details. #### 2026-04-09 **Marketing API** - Added `references` array to marketing consents response model. References are typed links to related entities (storefronts, bookings, orders) that can be used to fetch additional details. See [Get marketing consents](/apis/marketing/getmarketingconsents) for details. **Gift Card API** - Added new Gift Card API with endpoints to list and retrieve gift cards. See [Get gift cards](/apis/gift-card/getgiftcards) and [Get gift card](/apis/gift-card/getgiftcardbyid) for details. - Added `gift-card.read` OAuth scope for accessing gift card data. #### 2026-03-26 **Marketing API** - Added webhook for new marketing consents. See [Marketing consent created](/apis/marketing/marketingconsentcreated) for details. - Added `id` to marketing consents response model as a stable reference for delta loading on the [Get marketing consents](/apis/marketing/getmarketingconsents) endpoint. #### 2026-03-20 **Events API** - Added `experience_id` query parameter to `GET /v1/events` to filter events for a specific experience. **Orders API** - Added `EXTERNAL` transaction provider to order transactions. `EXTERNAL` indicates payment for an order was received in another system and marked as paid within Understory. #### 2026-03-03 **Events API** - Fixed `start_time` and `end_time` in Session to correctly return local time strings without timezone offset. The timezone is provided separately in the `timezone` field. #### 2026-02-24 **Bookings API & Experiences API** - Updated `locale` field description to include examples and improve clarity #### 2026-02-20 **Third-Party Integrations (Public Beta)** Third-party integrations are now available in public beta, enabling external applications to integrate with the Understory API on behalf of Understory customers. This feature allows developers to build applications such as: - Marketplaces - Marketing tools - Accounting systems Key capabilities: - OAuth 2.0 Authorization Code Grant flow for secure delegated authorization - Access and refresh token management - Scoped permissions to request only the access your application needs To get started, contact **integrations@understory.io** with your application details to receive OAuth 2.0 client credentials. Read the full guide at [Third-Party Integrations](/docs/usage/authentication/third-party-integrations). #### 2026-02-16 **Event API & Event Availability API** - Changed `from` and `to` filter parameters to accept local date-time without timezone (e.g., `2025-01-15T09:00:00` instead of `2025-01-15T09:00:00Z`). The filter is matched against the event's local start time. #### 2026-01-30 **Webhooks API promoted to Alpha** The Webhooks API has been promoted from Preview to Alpha status. This means the API is now available for integration, though changes may still occur. See [API Versioning](/docs/about/api-versioning#stable-previews-and-alpha-apis) for details. #### 2026-01-26 **Webhooks API (Preview)** - Added `BaseEvent` schema that defines the common envelope structure (`id`, `type`, `timestamp`, `payload`) for all webhook events #### 2026-01-09 **Webhooks API (Preview)** The Webhooks API is now available in preview. *As a preview API, this is currently a draft and is subject to change without notice.* This API enables you to: - Create and manage webhook subscriptions to receive real-time notifications - Subscribe to events for experiences, events, and bookings Key features: - Webhook subscription management (create, list, get, update, delete) - Signature verification using HMAC-SHA256 for secure webhook delivery - Secret key returned on subscription creation for signature verification Available webhook events: - Experience: `v1.experience.created`, `v1.experience.updated`, `v1.experience.deleted` - Event: `v1.event.created`, `v1.event.updated`, `v1.event.cancelled`, `v1.event.completed`, `v1.event.deleted` - Booking: `v1.booking.created`, `v1.booking.updated`, `v1.booking.cancelled` The specification can be inspected in [API Reference: Webhook](/apis/webhook). #### 2025-12-19 **Experiences API** - Restructured `InformationRequest` model to support multiple input types via discriminator pattern - Added `TextInformationRequest` schema for free-form text input fields - Renamed `label` to `question` for clarity on what is presented to the guest - Promoted `Get information requests` and `Get ticket variants` endpoints to Alpha #### 2025-12-18 **Event Availability API** - Renamed `remaining` to `cutoff_time` in `BookingCutoffConstraint` for clarity **Other improvements** - Added default error responses to information requests and ticket variants endpoints - Fixed `Accept-Language` header handling in Experiences API #### 2025-12-17 **Events and Experiences APIs promoted to Alpha** The Events and Experiences APIs have been promoted from Preview to Alpha status. This means they are now available for integration, though changes may still occur. See [API Versioning](/docs/about/api-versioning#stable-previews-and-alpha-apis) for details. Additional improvements in this release: - Added `UNKNOWN` to state and visibility enums for better forward compatibility - Added `INACTIVE` state to the Experiences API - Improved error responses with proper 403 and 404 status codes - Updated Metadata schema to use `additionalProperties` with string values **Event Availability API updates** - Renamed `SeatsLimitConstraint` to `EventSeatsLimitConstraint` (type: `EVENT_SEATS_LIMIT`) - Added new `EventStateConstraint` (type: `EVENT_STATE`) for event state-based availability **Pagination improvements across APIs** Pagination parameters have been standardized across the Bookings, Grow, Events, and Experiences APIs: - Added explicit `minimum: 1` and `maximum: 100` constraints to limit parameters - Improved documentation for cursor and limit parameters #### 2025-12-11 The Event Availability API is now available in alpha. This API allows querying availability for events, including remaining capacity and constraint information such as seat limits, booking limits, ticket limits, and booking cutoff times. The specification can be inspected in [API Reference: Event Availability](/apis/event-availability). #### 2025-10-10 The Experiences API has been updated. Specifically, the `media` property in the `image` variant no longer has a `preview_url` field. #### 2025-09-30 The Experiences and Events preview APIs have been updated. This change includes a lot of changes to the general models while preserving the available data. - Experiences are no longer differentiated by being shared or not. All experiences should be considered the same. - Events now include sessions which contains the specific date and time for when the event is held. This moves a lot of fields from experiences into sessions for better separation and composability. - Computed fields have been removed from events' capacity. These can be calculated client side if needed based on `total` and `reserved` fields on the Capacity model. #### 2025-04-29 The Bookings API is moved to `Alpha`. This means the API is available for integration but changes might still occur. Read the [API Versioning](/docs/about/api-versioning#stable-previews-and-alpha-apis) article for more details. - `POST /v1/bookings`: A new optional request body field `metadata` is added to allow for custom key/value pairs of metadata to be attached on the booking for later reference. - `POST /v1/bookings`: The endpoint now only returns the ID and status of a successfull booking operation. #### 2025-04-08 The Events API is now available in early preview. The specification can be inspected in [API Reference: Event](/apis/event). #### 2025-04-07 The Experience API is now available in early preview. The specification can be inspected in [API Reference: Experience](/apis/experience). #### 2025-04-03 The Bookings API is now available in early preview. The specification can be inspected in [API Reference: Booking](/apis/booking). #### 2025-03-20 This release adds marketing consents to the API enabling marketing automation flows. Read more about the API in the [API Reference: Get marketing consents](/apis/marketing/getmarketingconsents).