How SDK versioning works

Learn about Stripe's versioning and support policy for SDKs.

Stripe’s SDK versioning policy is based on the semantic versioning standard. For example, in version 4.3.2, 4 is the major, 3 is the minor, and 2 is the patch. When we release a new SDK version for new features or bug fixes, we increment one of these three version components depending on the type of change introduced.

Major. We increment the major version component when the version contains breaking changes that are backwards incompatible with the latest version: to add a required parameter, change a type, property, method, or parameter. For example, renaming the SDK’s exception classes.
Minor. We increment the minor version component when the version contains new features that are backwards compatible with the latest version: to add a new type, property, method, optional parameter, or supported parameter value. For example, clarifying the SDK’s metadata deletion message.
Patch. We increment the patch version component when the version contains backward-compatible bug fixes: to modify a behavior if correcting that behavior doesn’t change any documented types, properties, methods, or parameters. For example, fixing a bug where file uploads weren’t listed properly.

Each SDK version uses the API version that is current at the time of its release to make API requests. Refer to Set a Stripe API version to see how to override this.

Stripe SDK support policy

New features and bug fixes are released on the latest major version of the SDK. If you’re on an older major SDK version, we recommend upgrading to the latest major version to take advantage of these features and bug fixes. Older major versions of the package continue to be available for use, but won’t receive any additional updates.

Migration guides

We provide migration guides to help you upgrade from older major SDK versions. You can find them in the wiki section of our SDK GitHub repositories. The same wiki also has the mapping between SDK major versions and the API versions.

Stripe SDK language runtime version support policy

When a language runtime version reaches its end of life, we mark it as “deprecated” in the tables below and begin its extended support window. The exact length of the extended support window varies by language, but the range is 1 to 2 years.

After the extended support window for a language version ends, the following major version of the SDK will no longer support that language version. However, previous versions of the SDK will still be compatible with those older language versions. We’ll pre-announce all runtime deprecations on this page, in each SDK’s README, and in each language’s changelog.

Warning

Though an SDK might continue to work on an unsupported language version, don’t continue to use it. SDKs that run on unsupported versions might break unexpectedly in any release, and the cause of that breakage might not be included in the changelog.

Language policies

We support Python 3.9+. This includes all versions of Python that are currently receiving security support, plus those within the extended support window.

Python versions that have reached their end of life dates will begin an extended support window of 1 year (two major API releases). We’ll drop support for the oldest supported Python version with the March API release every year.

Here’s the deprecation schedule:

Python version	Status	End of life	support dropped	Last Compatible SDK	Notes
3.14	supported	October 2030	March 2032	TBD
3.13	supported	October 2029	March 2031	TBD
3.12	supported	October 2028	March 2030	TBD
3.11	supported	October 2027	March 2029	TBD
3.10	supported	October 2026	March 2028	TBD
3.9	deprecated	October 2025	March 2027	TBD
3.8	unsupported	October 2024	March 2026	`v14.4.1`	3.8 is the first version to lose support on the schedule defined in this policy.
3.7	unsupported	June 2023	March 2026	`v14.4.1`	To ease the transition into this policy, we’re lengthening the support window for 3.7 to give users more time to update their integrations.
3.6	unsupported	December 2021	September 2025	`v12.5.1`	The decision to drop 3.6 predates this policy and as a result, doesn’t follow the above pattern.

Public preview release channel

We have a public preview release channel, which uses preview API versions that are distinct from general availability (GA) versions. For example, 2025-04-30.preview instead of 2025-04-30.basil. The current preview API version is 2026-09-30.preview.

To access the new features and enhancements in the preview stage, use versions of our SDKs that have the beta or b suffix. For example, 5.1.0b3 in Python and 5.1.0-beta.3 in other language SDKs.

For installation instructions and details about passing preview headers in the Stripe-Version header, see the Public Preview SDKs section in the README files in the respective SDK GitHub repositories.

Private preview release channel

We also publish features in the private preview phase that require invite-only access. These features also use the preview API versions.

To access private preview features and enhancements after invitation, use versions of our SDKs that have the alpha or a suffix. For example, 5.1.0a3 in Python and 5.1.0-alpha.3 in other language SDKs.

For installation instructions and details about passing preview headers in the Stripe-Version header, see the Private Preview SDKs section in the README files in the respective SDK GitHub repositories.