These notes describe customer-visible changes currently on staging compared to production as it runs today. They cover API and dashboard behavior only—not internal tooling, tests, or infrastructure.

Baseline: content reflects deltas relative to the 3.0.0 platform line on production; staging may include work slated for a future minor or patch release. Use staging to validate integrations before these changes reach production. Exact production timing will be communicated separately.

Features

• Bookings per time slot (allocations) — Weekly and single allocations support an optional bookingsPerSlot value (minimum 1) where the API accepts it, so you can cap how many bookings may share the same slot for a given allocation. The dashboard allocations experience was updated to support this.
• Weekly allocations: service and resource together — Creating a weekly allocation may include both ServiceId and ResourceId when your integration needs that combination. The API no longer rejects requests solely because both identifiers are present.
• Service weekly unavailability — Service-level weekly unavailability can be associated with an optional resource when you need resource-specific unavailability in a service context.
• Appointment reserve (RS) without hold expiry — POST /v3/appointment/reserve lets you place an appointment in reserved (RS) state when you need that outcome without relying on a short-lived hold window. Use this when your product flow reserves first and confirms later. OpenAPI and the appointment guides were updated for reserve, confirm, and calendar behavior alongside this.
• Support requests (API) — The create-ticket request still supports the legacy shape (subject and body only). You can also send a structured request with additional fields (for example environment, product area, topics, and optional request metadata) when you want the support platform to receive a richer, labeled ticket. Existing simple integrations can keep using subject and body unchanged.

Improvements

• Availability — Availability behavior for allocation-based scheduling was improved, including clearer handling in edge cases that involve resources, services, and validation of bookable slots. Availability and slot validation now apply bound parameters consistently through allocation-related SQL (including optional fallbacks where CTEs need them), which reduces subtle mismatches between computed slots and what the API will accept when booking.
• Unavailability reasons — Additional reason values are supported where the API exposes unavailability reasons, giving more accurate classification without changing how you authenticate or call the API.
• Legacy (v1-style) API usage — Integrations that rely on v1-compatible behavior benefit from compatibility and reliability improvements across those flows (no change to your obligation to use current credentials and endpoints as documented). The v1 reserve shim now sends a valid book payload and persists reserved (RS) state so downstream steps behave like native v3 flows.
• Appointment by ID — The appointment-by-id response may include customer data so integrations and UI can show who the booking is for without an extra customer lookup in typical cases.
• Calendars on delete — When deleting an appointment, the API loads resource-level external calendar configuration as needed so external cancellations align with the calendars actually in use.
• Reserved (RS) state and delete — Delete routes handle RS appointments correctly for cancellation and permanent deletion expectations (including cases that previously left reserved rows or external state out of sync).
• OpenAPI — The confirm appointment operation in OpenAPI now matches the live implementation; the bundled openapi.json was refreshed accordingly.

Dashboard

• Allocations — Forms and flows for managing allocations align with the API changes above (including bookings-per-slot where applicable).
• Support — The in-app support request experience supports the same legacy and structured options as the API, so users can submit either a short message or a structured request when the product presents those fields.

These notes describe customer-visible changes currently on staging compared to production as it runs today. They cover API and dashboard behavior only—not internal tooling, tests, or infrastructure.

Use staging to validate integrations before these changes reach production. Exact production timing will be communicated separately.

Features

• Bookings per time slot (allocations) — Weekly and single allocations support an optional bookingsPerSlot value (minimum 1) where the API accepts it, so you can cap how many bookings may share the same slot for a given allocation. The dashboard allocations experience was updated to support this.
• Weekly allocations: service and resource together — Creating a weekly allocation may include both ServiceId and ResourceId when your integration needs that combination. The API no longer rejects requests solely because both identifiers are present.
• Service weekly unavailability — Service-level weekly unavailability can be associated with an optional resource when you need resource-specific unavailability in a service context.
• Support requests (API) — The create-ticket request still supports the legacy shape (subject and body only). You can also send a structured request with additional fields (for example environment, product area, topics, and optional request metadata) when you want the support platform to receive a richer, labeled ticket. Existing simple integrations can keep using subject and body unchanged.

Improvements

• Availability — Availability behavior for allocation-based scheduling was improved, including clearer handling in edge cases that involve resources, services, and validation of bookable slots.
• Unavailability reasons — Additional reason values are supported where the API exposes unavailability reasons, giving more accurate classification without changing how you authenticate or call the API.
• Legacy (v1-style) API usage — Integrations that rely on v1-compatible behavior benefit from compatibility and reliability improvements across those flows (no change to your obligation to use current credentials and endpoints as documented).

Dashboard

• Allocations — Forms and flows for managing allocations align with the API changes above (including bookings-per-slot where applicable).
• Support — The in-app support request experience supports the same legacy and structured options as the API, so users can submit either a short message or a structured request when the product presents those fields.

• info about the changelog
• blah blah blah
• updated