Versioning & Deprecation Policy

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 and this policy. Every dated entry lists the reference groups it affects and whether it is breaking.

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.

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.

COUNT publishes at least 90 days of notice before a breaking change takes effect. Notice is given as a changelog entry with breaking: true, naming every affected reference group and the date the change takes effect.

• Check the changelog periodically, or diff /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 if a scheduled breaking change needs more lead time for your integration.