Changelog and deprecation policy

The Clearslot Developer API Terms cover your use of the API. They form part of the Clearslot Terms of Service.

Deprecation policy

Version one (/api/v1) changes only by adding: new routes, new optional parameters, new response fields and new event types. Write clients that ignore fields and event types they don't know.
A deprecated route or field keeps working. Its responses send Deprecation and Sunset headers, with a Link to its entry on this page. Key creators are emailed when a deprecation affects routes they call.
A change that breaks existing integrations ships only as a new major version, with at least 12 months of overlap. A shorter period applies only when it is needed to fix a security problem or to comply with law (Developer API Terms, section 5).
Every change is listed below, newest first. A deprecation entry names the route or field, what replaces it and its sunset date.

General availability for businesses on Pro or a complimentary plan.

API keys with permissions, expiry and an optional IP allowlist, created in Settings → Developers.
Reads across the business: the organization and its members, booking links, services, classes, resources, routing forms and their submissions, availability slots, busy times, schedules, bookings, customers and booking reports.
Writes: creating, rescheduling, cancelling, confirming and declining bookings and marking no-shows; quick invites; meeting links; weekly hours, date overrides and blocked time; customers, including erasure.
Webhooks signed with Standard Webhooks, with retries for about three days, a delivery log, replay, and endpoints that integrations can manage through the API.
The event feed (GET /api/v1/events), signed cursors and updatedSince sync, idempotent writes, published limits with X-RateLimit-* headers, and errors with a stable code and a link to their documentation.