x-v

Versioning & Lifecycle de facto — unregistered response reached by regulation 2 spellings

Australia’s Consumer Data Standards handle versioning in headers: the client sends x-v for the version it wants and optionally x-min-v for the oldest it will accept, and the server answers with the version it actually used.

What makes it notable is not the mechanism, which is sound and unremarkable, but its status. The Data Standards Chair makes the Consumer Data Standards binding under the CDR rules — so in Australia, the way you negotiate an API version is not a design preference. Sixty-one providers declare it, which is approximately the population of the Australian CDR regime in this catalog.

Every other market solves the same problem in the URL path, and argues about it endlessly. Australia legislated an answer.

The registry

Not registered with IANA. It is a de facto or vendor field — real, widely used, and governed by nothing but convention.

In the catalog

Declared by 122 providers across 6,342 published specification files in the API Evangelist catalog, where it appears as a response header — sent by the server.

It is spelled 2 different ways across those contracts — x-v, XV. HTTP field names are case-insensitive (RFC 9110, §5.1), so every one of these is the same header. They are not the same string, which is why generated clients disagree about it.

Reached by regulation

This header is mandated: the law, or a technical standard the law makes binding, names it directly. Only a credentialed caller can watch it in flight. The catalog can see that a contract declares it; it cannot see that a deployment honours it, and this site never claims otherwise.

Using it

Outside the CDR, do not adopt x-v — it is a regime-specific spelling and borrowing it just adds a dialect. Inside the CDR, follow the standard exactly, including returning x-v on the response with the version actually served, which is the part implementations most often skip.