OneHazel Docs

Appearance

For LLMsView as Markdown·

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 with a complete error reference, a consolidated rate limits page, an environments page, a security and data handling page, a link to 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.