Versioning policy

Versions in the pathCopy Anchor Link

The version is part of every path: https://data.decryptr.ai/v1/.... A version only ever gets changes that will not break a well-behaved client. Anything that would break one goes into a new version, such as /v2, and the old one keeps running alongside it.

What we may change without a new versionCopy Anchor Link

• Add endpoints.
• Add optional query parameters.
• Add fields to responses, including new properties in nested objects.
• Add values to an enum documented as open, such as a new error code.
• Add response headers.
• Change the order of fields in JSON.
• Change error title and detail text (the code stays the same).

Write your client so it ignores fields and enum values it does not know. Do not depend on field order.

What counts as breakingCopy Anchor Link

• Removing or renaming an endpoint, parameter or field.
• Changing a field's type or meaning.
• Making an optional parameter required.
• Changing how calls are counted for an endpoint.
• Changing authentication.

Notice before anything is removedCopy Anchor Link

We announce a deprecation at least 6 months before the removal date, in the changelog and by email to the owner of every key that used the affected endpoint in the last 90 days.

From the announcement, responses from the affected endpoint carry two headers:

Deprecation: @1793318400
Sunset: Fri, 30 Apr 2027 00:00:00 GMT
Link: <https://www.decryptr.ai/developers/changelog>; rel="deprecation"

Deprecation is when it was deprecated (RFC 9745) and Sunset is when it stops working (RFC 8594). Log these headers in your client so you hear about a change even if an email is missed.

The exception is a change the law or a data source requires, such as removing a field we may no longer provide. We give as much notice as we can.

The OpenAPI specCopy Anchor Link

The API reference is generated from our OpenAPI 3.1 spec, which is the source of truth for v1. Endpoints that are not in the spec are not part of the API.