API versions | Overlane Docs

The API version is a date in a header. A breaking change ships as a new version with a changelog entry, and an old version keeps working at least twelve months after the next one ships.

The API version is a date. Send it in the Overlane-Version header, or leave the header off for the current version. See REST API.

overlane api versions

The rule

A breaking change (a removed or renamed field, a changed meaning, a removed route) ships only as a new version, with an entry in the changelog that lists exactly what broke.
A change that only adds (a new route, a new optional field, a new event type) does not need a new version.
When a version is replaced, it keeps working for at least twelve months after the next version’s release date. Its end date is published here and in overlane api versions.
A snapshot of the OpenAPI document is kept for every version, so you can read exactly what you built against.

Versions

Version	Released	Supported until	What it is
2026-10-10	2026-10-10	the newest version	First dated version: connectors, API keys, outbound webhooks, rate limit headers and the generated OpenAPI document

assert.equal(API_CHANGELOG.at(-1).version, CURRENT_API_VERSION);
assert.equal(changelogProblems(API_CHANGELOG).length, 0);
// A version replaced after only four months fails the twelve month rule.
const soon = [
  { version: "2026-10-10", releasedAt: "2026-10-10", supportedUntil: "2027-02-01", breaking: [], summary: "a" },
  { version: "2026-11-01", releasedAt: "2026-11-01", supportedUntil: null, breaking: ["renamed a field"], summary: "b" },
];
assert.equal(changelogProblems(soon).length, 1);
assert.equal(MIN_SUPPORT_MONTHS, 12);

The changelog is data in the contracts, and the rule above is a function over it that a test runs, so a version cannot be retired early by editing a date.