# Changelog and deprecation policy

## Changelog

Customer-visible changes to the OneHazel API and platform, newest first. This changelog starts on 2026-10-11; earlier changes are not listed.

### 2026-10-11

- **Added:** a [reference section](/reference/) with a complete [error reference](/reference/errors), a consolidated [rate limits](/reference/rate-limits) page, an [environments](/reference/environments) page, a [security and data handling](/reference/security) page, a link to [service status](/reference/#service-status), and this changelog and deprecation policy.
- **Clarified:** rate-limit windows are one wall-clock minute, aligned to the clock, and the reset time is returned as `error.retryAfter` (an ISO 8601 timestamp) and the `X-RateLimit-Reset` header on the main API and gateway. Earlier pages described this as a token bucket with a `resetAt` field.

## Deprecation policy

### What counts as a breaking change

A change is breaking if a correct, existing integration could stop working because of it. For example:

- removing an endpoint, a field in a response, or an accepted value of a request field;
- making an optional request field required;
- changing the type or meaning of an existing field;
- changing the HTTP status or error `code` returned for an existing situation;
- lowering a published rate limit.

These are **not** breaking, and can ship at any time without notice: new endpoints, new optional request fields, new response fields, new error codes for situations that did not previously produce an error, new webhook event types, wording changes to error `message` text, and raising a rate limit. Build your client to ignore fields and event types it does not recognise, and to branch on error `code`, not `message`.

### Versioning

The API is currently unversioned: there is one version, served at `https://api.onehazel.com`. We evolve it by adding, not by changing. If a breaking change is ever unavoidable, we will introduce it alongside the existing behaviour (for example as a new endpoint or an opt-in), not in place of it.

### Notice period

We give at least **90 days' notice** before removing or breaking anything an integration relies on. During the notice period the old behaviour keeps working. Security fixes are the exception: if keeping old behaviour would put customer data at risk, we may change it sooner and will tell affected customers directly.

### Where breaking changes are announced

- In this changelog, marked **Deprecated** when announced and **Removed** when the change takes effect.
- By email to the owner of each affected operator account.