Skip to main content
The API carries two version numbers. They answer different questions.

​
API version

Every endpoint lives under /api/v1. The prefix changes only for a breaking change to the wire contract, which would move to a new prefix such as /api/v2.
While the API is in beta, treat the contract as settling rather than frozen. Release 1.0.0 renamed two fields under /api/v1 without a prefix change — see the changelog. Breaking changes are always listed there.

​
Release

The release follows semantic versioning and is published as info.version in the OpenAPI spec:
  • Patch (1.0.0 → 1.0.1): fixes and operational changes. No change to the contract.
  • Minor (1.0.x → 1.1.0): backwards-compatible additions, such as a new optional field.
  • Major (1.x → 2.0.0): a breaking change to the contract.
A release can ship with no visible change to the API. The changelog says so when that happens.

​
What counts as a breaking change

Breaking:
  • Removing or renaming an endpoint, request field, or response field.
  • Changing the type of an existing response field.
  • Tightening validation on a field that previously accepted broader input.
  • Changing the JSON error envelope.
Not breaking:
  • New endpoints.
  • New optional response fields.
  • New optional request fields.
  • Fixes that bring actual behaviour in line with documented behaviour.
Write your client so that unknown response fields are ignored. That is what makes non-breaking additions safe.

​
Discovering changes

  • Read the changelog for material changes and the release each shipped in.
  • Diff the OpenAPI spec between deploys for a precise record of contract changes.
  • Email support@thedatacity.com with questions about a specific change.
Last modified on September 4, 2026