---
title: "Versioning & Deprecation Policy · COUNT Partner API"
description: "How COUNT classifies breaking vs. non-breaking Partner API changes, the notice given before one ships, and how to track compatibility."
canonical: "https://developers.getcount.com/resources/versioning-and-deprecation"
source: "https://developers.getcount.com/resources/versioning-and-deprecation"
---
Resources

# Versioning & Deprecation Policy

How COUNT defines breaking vs. non-breaking Partner API changes, the minimum notice before a breaking change ships, and how to track compatibility since the API has no version header.

## Current versioning model

The Partner API does not send or accept a version header, query parameter, or path segment today — every route is mounted flatly under `/partners`. There is no `v1` to pin to and no `Accept-Version` header to negotiate.

Compatibility is instead communicated entirely through the [changelog](https://developers.getcount.com/changelog) and this policy. Every dated entry lists the reference groups it affects and whether it is breaking.

No request-side version to set

You do not need to send anything to opt into a version. Non-breaking changes apply automatically; breaking changes are announced with the minimum notice below before they take effect.

## Non-breaking changes

Ship without advance notice. Well-behaved clients are not affected by:

- Adding a new optional field to a response or request body.
- Adding a new endpoint or a new optional query parameter.
- Adding a new enum value to a field, when the field is documented as open-ended.
- Relaxing validation (making a previously required field optional, widening an accepted range).
- Fixing a response to match its documented shape (correcting a bug, not a contract).

Build your integration to ignore unrecognized fields and unrecognized enum values so these changes never break parsing.

## Breaking changes

Require the minimum notice period below before taking effect:

- Removing or renaming a field, endpoint, or query parameter.
- Changing a field's type or semantic meaning (for example, a value that changes units).
- Removing a previously supported enum value.
- Tightening validation (making an optional field required, narrowing an accepted range).
- Changing authentication or authorization requirements for an existing route.

## Minimum notice period

COUNT publishes at least **90 days** of notice before a breaking change takes effect. Notice is given as a [changelog](https://developers.getcount.com/changelog) entry with `breaking: true`, naming every affected reference group and the date the change takes effect.

Track the groups you use

There is no per-request opt-out for a breaking change once its effective date arrives. Monitor the changelog for entries affecting the reference groups your integration calls.

## How to stay current

- Check the [changelog](https://developers.getcount.com/changelog) periodically, or diff [/openapi.json](https://developers.getcount.com/openapi.json) between releases — its `info.version` is the date of the most recent changelog entry.
- Ignore unrecognized response fields and enum values rather than failing parsing on them.
- Contact [support@getcount.com](mailto:support@getcount.com) if a scheduled breaking change needs more lead time for your integration.