Skip to main content
The Developer API uses date versions — 2026-08-22 is the current (and founding) version. When the API needs a breaking change (a renamed field, a reshaped response), that change ships as a new date. Every older version keeps behaving as it did. Additive changes — new endpoints, new optional fields — arrive in all versions and never create a date.
An integration keeps receiving the shapes of its pinned version until it is upgraded.

​
The key is pinned

Every API key is pinned to the version that was current when the key was created. A request without a version header is served in the key’s pinned version. The console’s API keys page shows each key’s pinned version in the API version column.

​
Overriding per request

Send the Orriven-Version header to serve a single request in a different version — to test a newer version before committing to it:
An unknown date returns 400 and names the versions that exist. Only published dates are valid.

​
Every response includes its version

Whatever decided the version — the header or the key’s pin — the response echoes it:
Log this header. When reading old logs during an upgrade, it shows which shape each response used.

​
Upgrading

1

Read the changelog

Each new version’s entry (below) says what changed, from the caller’s side.
2

Test with the header

Point a staging integration at the new date with Orriven-Version. The key’s pin is untouched. Production traffic keeps its old shape.
3

Move the pin

Generate a new key (it pins to the latest version automatically), switch the integration to it, then revoke the old key — the same zero-downtime rotation as any credential change.

​
Changelog

API keys

Where a key’s pinned version lives.

Endpoint reference

The current version’s shapes, endpoint by endpoint.