Skip to main content
The version lives in the path: every endpoint sits under /api/export/v1/.

​
What can change within v1

We treat these as additive and ship them without a version bump:
  • New endpoints.
  • New fields on an existing response.
  • New optional query parameters.
  • New values in a field that was already free-form text, such as a new AI model appearing in model_id.
A change that would break a correct client — removing or renaming a field, changing its type, or changing the meaning of an existing value — does not ship inside v1. It gets a new version path, and v1 keeps working alongside it.

​
Building a client that survives additions

  • Ignore fields you do not recognize. Do not fail a parse because a new column appeared.
  • Select the columns you need by name rather than by position, and rather than mapping “everything in the row” straight into a fixed schema.
  • Do not hardcode the set of models, providers, or markets. New AI assistants get added as we start tracking them.
  • Read pagination and meta rather than assuming. Page size, and the window your plan allows, are reported on every response for exactly this reason.

​
The specification is the contract

The OpenAPI document is generated from the running code, so it describes what the API returns right now rather than what was true when someone last edited a page. If this documentation and the specification ever disagree, the specification is correct — and the disagreement is a bug worth telling us about.