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