> ## Documentation Index > Fetch the complete documentation index at: https://openphone-dev.mintlify.site/llms.txt > Use this file to discover all available pages before exploring further. # Versioning > How date-based versioning works, what a version guarantees, and what counts as a breaking change. You run a business on Quo. We ship changes to Quo every week. Versioning is what keeps those two facts from colliding: the API you built against today will behave the same way next month and next year, regardless of what we ship in between. ## How it works Every version is a date. Every request declares which date it was built for: ```bash theme={null} Quo-Api-Version: 2026-03-30 ``` The header is **required on every request**, and there is no default version. That's deliberate. A default would mean your integration's behavior could change because of something *we* did. Requests without the header fail with a `400` that says exactly that. When you make a request with `Quo-Api-Version: 2026-03-30`, you get the API exactly as documented on these pages, today and for as long as the version exists. ## What changes, and what never does A version is frozen the day it ships. "Frozen" applies to behavior, not to size: a version can keep growing without breaking you. Ships without a new date: * New endpoints * New optional request parameters * New fields in responses * Bug fixes and security patches, in any supported version Requires a new dated version, leaving your integration untouched until you opt in: * Removing or renaming a field, parameter, or endpoint * Changing a field's type or format * Changing existing behavior in a way your code could observe One habit follows from this: **write your integration to ignore response fields it doesn't recognize.** New fields are the one way the API changes underneath you, and never in a way that alters what existing fields mean. A new version is cut only when a breaking change is genuinely necessary, not on a schedule. Long stretches with no new version are expected. ## Why a date in a header The previous generation of this API put the version in the URL: `api.quo.com/v1/messages`. This generation moves it to a header and replaces `v1`/`v2` counters with dates. Both choices are deliberate. * **URLs name resources; headers describe requests.** `/users` is the same collection of people whichever version you view it through. Keeping the version out of the path means links, logs, and saved requests stay stable across upgrades. * **A date answers the question a counter raises.** "v3" tells you nothing except that v2 exists. `2026-03-30` tells you exactly how old your assumptions are. * **Upgrades become a one-line diff.** Moving to a future version means changing one header value, then reading the changelog entries between your date and the new one. Your URLs and tooling stay put. ## Retiring a version No version disappears quietly. If a version is ever scheduled for retirement, we'll announce it in the [changelog](/2026-03-30/changelog) with a migration window and a precise list of what changed. Follow the changelog by RSS to hear about additions and version announcements the day they happen. ## Coming from v1 The [v1 API](/mdx/api-reference/introduction) remains fully supported and is not going anywhere without the notice described above. * **Building something new?** Start here, on `2026-03-30`, if the [endpoints you need are available](/2026-03-30/introduction#whats-available-today). This is where all new capability ships. * **Running on v1 today?** Stay put until this version covers your surface. We're adding endpoints steadily and recording each one in the changelog. There's no advantage to migrating early; when the coverage is there, migrate once and get the contract above.