Skip to main content
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: 
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 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 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. 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.