API versioning: when and how to break compatibility

What it is

An API version is a promise about which requests keep working. Google's design guide recommends a major version in the path (/v1/) and treats backwards-incompatible changes (removing or renaming fields, changing types or semantics, tightening validation) as requiring a new major version, while additive changes (new optional fields, new endpoints) do not.

Why it matters

Every live major version is a codebase to maintain and test. Additive evolution keeps one version alive for years; unnecessary version bumps fragment clients.

How to apply

• Write down what counts as compatible: adding optional fields and new enum values (if clients are told to ignore unknown values), relaxing validation.
• Never reuse or change the meaning of an existing field; add a new one and deprecate the old with a date.
• Announce deprecations in the schema and in responses (a Deprecation or Sunset header, or documentation) and keep both for an overlap period.
• Bump the major version only for changes that cannot be made additively, and publish a migration guide.

Pitfalls

Versioning by date or by header without documentation confuses clients. "Minor" tightening of validation breaks real callers. Removing a field that "nobody uses" without measuring usage.