Versioning

ChronaPilot uses date-based API versioning. Every breaking change is gated behind a new version date. You pin a version per-key in the dashboard, or override per-request with the Chronapilot-Version header.

Header

HTTP
Chronapilot-Version: 2026-05-20

When you create a new API key, it defaults to the latest version available at that moment. Existing keys keep using the version they were created against.

Per-request override

Useful when migrating: test a new version on staging without flipping the default for your key.

curl
curl https://api.chronapilot.com/v1/events \
  -H "Authorization: Bearer sk_live_…" \
  -H "Chronapilot-Version: 2026-05-20"

What counts as a breaking change

The following are versioned (require a new date):

Removing a field from a response.
Changing the type of a field.
Renaming a field.
Changing the meaning of an enum value.
Tightening required parameters.

The following are non-breaking and roll out without a version bump:

Adding a field to a response.
Adding a new endpoint.
Adding a new enum value (always paired with documentation of "unknown" handling).
Loosening a constraint.

Deprecation

Once a version is superseded, it stays supported for a minimum of 12 months. The Chronapilot-Deprecation-Date response header tells you when your pinned version sunsets.

Changelog

See the changelog for every version's notes.