Versions

The API stays at /v1. Changes that could break an integration ship only in a new, dated contract, and every key chooses when it moves. These are the contracts:

2026-10-01 (the newest: new keys are pinned to it, and the SDKs send it)
2026-07-08 (the v1.0 contract: keys made before 2026-10-01)

Which contract a request runs in#

Every key is pinned to the contract that was current when it was made. GET /v1/me shows it: apiKey.apiVersion.
A request may send Zentiq-Version: <date> to run in its key's contract or a newer one. Use it to try the newer contract before you move for good. A value that isn't a contract, or is older than the key's, is 400 invalid_request with param: "header.Zentiq-Version": a request never runs in a contract you didn't mean.
Every answer says which contract it was written in, in its own Zentiq-Version header.
A webhook's deliveries are written in the contract of the key that made it. PATCH /v1/webhooks/{id} with apiVersion moves it.

The SDKs send the newest contract with every request.

What changes, and when#

Change	Where it ships
New operations, new fields in answers, new event types, new values in a list of values	Any day, in every contract. Ignore what you don't know.
Removing or renaming a field, a new required input, a changed meaning, a new error for a request that worked	Only in a new contract.
Privacy and security fixes	Every contract, the day they ship. They take things away (a field that should never have left Zentiq), never change what a field means.

Every change is in the changelog, dated, with who needs to act. A contract stays supported for at least twelve months after the next one ships.

Moving to 2026-10-01#

Keys made from 2026-10-01 are on it already. For an older key, read Moving to 2026-10-01, test with the Zentiq-Version: 2026-10-01 header, then make a new key and retire the old one.