At Fingerprint, we regularly release updates to our JavaScript agent, APIs, and SDKs, to give you more features, increased security, and better performance. Sometimes, this means older versions of our APIs will no longer be supported.
Quick overview
- All of your APIs and SDKs follow semantic versioning.
- Major releases of the JavaScript agent, Android SDK, iOS SDK, and all server-side APIs follow our Deprecation and notice policy. You will have 1 year from the major version release date to upgrade your implementation using the provided migration guides.
- Client and Backend SDKs are wrappers for the underlying JavaScript agent, mobile SDKs, or server-side APIs. They follow their own semantic versioning. The Deprecation and notice policy applies to them only when the underlying SDK or API is deprecated.
Semantic versioning
All of our products are versioned using the Semantic versioning format MAJOR.MINOR.PATCH
.
- We increment the
PATCH
version, for example, from1.2.0
to1.2.1
, when we make backward-compatible bug fixes. You can upgrade to a new patch version without making any changes to your application. - We increment the
MINOR
version, for example, from1.2.1
to1.3.0
, when we add new features without any breaking changes. You can upgrade to a new minor version without making any changes to your application.
Note: We can also use MINOR releases to update mobile SDK runtime requirements, for example, dropping support for old versions of iOS or Android.
- We increment the
MAJOR
version, for example, from1.3.0
to2.0.0
, when we make improvements that require you to make changes to your application. Upgrading to a new major version requires updating your application’s code, dependencies, or minimum required platform version to follow the new contract.
Versioning REST APIs
REST and server-side APIs like Server API, Management API, Device Reputation Network API, Webhooks and Sealed client results only use the
MAJOR
version.
- Non-breaking changes and additions to these APIs can happen at any time.
- The API endpoint version is usually indicated by a query parameter (e.g.
/events?version=4
) or a path parameter (e.g./<version>/events
).
Deprecation and notice policy
When we release a new MAJOR version of the JavaScript agent, mobile SDKs, REST API endpoint, or another server-side API, the following policy applies since March 2025:
One-year migration period
- You will have one year from the release date to switch to the new major version.
- We recommend upgrading as soon as possible to avoid any disruptions. We will always provide detailed migration guides and our customer success team will work with individual customers to ensure a smooth transition.
- During the migration period, we will continue to support both the deprecated and the new versions. The deprecated version will receive security fixes, but no new features or improvements.
- After the migration period ends, the previous (deprecated) major version will stop working.
Deprecation notice
- We will inform you by email when a new major version is released. From this point, the previous major version is marked as deprecated and will stop working in one year.
- The relevant documentation will include a clear deprecation notice including the exact date of the API/SDK removal and end of support.
- If we detect you have not upgraded to the new version (for example, you are calling a deprecated API endpoint), we will send you reminder emails from [email protected] once a month. The email frequency will increase to once a week in the last month before the end of support.
Note: Some legacy APIs or SDKs might be deprecated without a direct replacement. In those cases, we will follow the same Deprecation and notice policy outlined above, including the one-year migration period.
The Deprecation and notice policy covers the following:
- JavaScript Agent
- iOS SDK
- Android SDK
- Webhook format
- Sealed client results format
- Server API (each endpoint can be versioned and deprecated individually)
- Management API (each endpoint can be versioned and deprecated individually)
- Device Reputation Network API (each endpoint can be versioned and deprecated individually)
Exceptions to the Deprecation and notice policy
Cloud proxy integrations
Cloud proxy integrations have a large number of internal dependencies (JavaScript agent, Identification API, etc.) and external dependencies (cloud platforms and their products).
- In most cases, cloud proxy integrations follow the Deprecation and notice policy.
- However, in exceptional circumstances beyond our control (for example, a sudden change in a cloud platform dependency), we might be forced to end support for a deprecated version of a cloud proxy integration in less than one year.
Wrapper SDKs
The Deprecation and notice policy does not generally apply to the following:
- Frontend SDKs: React, Angular, Svelte, Vue, etc.
- Multi-platform SDKs: React Native and Flutter.
- Server SDKs: Node, PHP, Go, Java, Python, and #C.
These SDKs (let’s call them wrapper SDKs) give you a smoother developer experience by providing utilities on top of the underlying JavaScript agent, mobile SDKs, and server-side APIs respectively.
- Wrapper SDKs follow their own semantic versioning.
- They can regularly release new major versions independently of the underlying SDK or API.
- The Deprecation and notice policy applies to them only when the underlying SDK or API is deprecated.
Example A (Policy does not apply)
If we release a major version of the Node SDK that uses the same version of the underlying Server API as before, the deprecation policy does not apply:
- For example, we improve the type signature of error utilities in the Node SDK. This breaking change (however small) requires releasing a new major version of the Node SDK. However, the SDK still uses the same version of the underlying Server API.
- Therefore, the previous Node SDK major version is NOT **deprecated, it stays available and continues to work.
- There are no notice emails or deprecation notices.
- The previous Node SDK major version continues to receive security fixes, but new features or improvements are only added to the latest major version.
- The previous Node SDK major version can become deprecated later:
- As a result of the Node SDK deprecation policy. For example, if the underlying Node version is deprecated.
- If the underlying Server API endpoint version is deprecated, as discussed below.
Example B (Policy applies)
If we release a major version of the Node SDK that uses a new major version of the underlying Server API, the deprecation policy applies:
- All previous major versions of the Node SDK, using the now deprecated version of the Server API are now also deprecated according to the Deprecation and notice policy.