Skip to main content
Credence versions its API to allow changes without breaking existing integrations. Each version is stable — once released, breaking changes are only introduced in new versions.

​
Specifying a version

Include the API version in the request path:
If no version is specified, requests default to the current stable version. Relying on the default is discouraged for production integrations.

​
API versions

Deprecated versions continue to function but no longer receive new features. Discontinued versions return an error.

​
Version lifecycle

Each API version moves through the following stages:
1

Available

The version is stable and recommended for production use.
2

Deprecated

The version still works but is no longer recommended. Plan to migrate.
3

Discontinued

The version is removed. Requests will fail.

​
Breaking vs. non-breaking changes

The following changes are considered non-breaking and can occur within an existing version:
  • Adding new API endpoints
  • Adding new optional request parameters
  • Adding new fields to responses
  • Adding new event types
  • Changing the order of fields in responses
  • Changing the length or format of opaque identifiers
The following are breaking and require a new version:
  • Removing or renaming endpoints, fields, or parameters
  • Changing the type of an existing field
  • Changing authentication or permission requirements for existing endpoints
  • Changing existing error codes or status codes

​
Handling version changes

  • Pin your integration to a specific version in the request URL.
  • Subscribe to changelog updates to track deprecations.
  • Ignore unknown fields in API responses so additive changes don’t break your client.
  • Test against the newest version before migrating production traffic.
Last modified on July 2, 2026