v3.1.0 Release

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.