Upgrade Stripe

by stripe08d371a9fbe0No licenseListed Oct 8, 2026Updated Oct 8, 2026

Guide for upgrading Stripe API versions, webhook endpoints, server-side SDKs, Stripe.js, and mobile SDKs

AI-generated overview

Guides upgrading Stripe API versions, webhook endpoints, server SDKs, Stripe.js, and mobile SDKs.

What it does
This skill provides instructions for planning and performing Stripe version upgrades. It covers choosing a target API version, comparing it against pinned versions, updating server-side SDKs, Stripe.js, and mobile SDKs, and reviewing webhook and event destination versioning. It also includes an upgrade checklist and guidance on testing version changes with the Stripe-Version header.
When to use it
Use it when an integration needs to move to a newer Stripe API version or when reviewing which Stripe components pin an API version. It is also relevant when checking webhook endpoints, event destinations, or SDK releases before and after an upgrade.
Requirements
Instructions only; no scripts are shipped. It may need network access to docs.stripe.com or the Stripe CLI to look up the current API version, and it references Stripe API keys and SDK package managers in examples.

Upgrading Stripe Versions

Choose a target API version

If the user specifies a target API version, use it. Otherwise, look up the current version on docs.stripe.com with any documentation or web tool available to you, for example stripe docs /api/versioning with the Stripe CLI. The API versioning page states it in the sentence that begins “The current version is”.

Bundled fallback API version: 2026-09-30.endive. This value is only a snapshot from the last time this skill was generated, on 2026-10-08. Version identifiers start with their release date in YYYY-MM-DD format and new stable versions are released monthly, so a fallback version dated more than a month ago is probably stale. Use it only when you can’t reach docs.stripe.com. Never guess about a newer version number.

Before making changes, compare the target with each API version the integration pins: client configuration, per-request overrides, and webhook endpoints. Unless the user explicitly asks for it, don’t move any pin to an older version or a stable pin to a preview version. If a pin already matches the target, report it as unchanged. State the selected target and its source. If live verification fails or is unavailable, say that the latest version remains unverified, and don’t claim the integration is on the latest version.

When reviewing webhook endpoints and event destinations, distinguish snapshot events from thin events. Thin event payloads are unversioned, so they don’t need to be upgraded when you change your API version. API calls that retrieve the full event or related resource remain versioned.

For SDKs that support explicit API version overrides, use the selected target in client configuration and per-request overrides. Use it in curl Stripe-Version test headers, too. Replace bundled API versions shown in those examples with the selected target before copying or running them. For Java, Go, and .NET, select an SDK release that targets the selected API version instead of overriding the SDK’s fixed version. Preview targets need the matching beta SDK release in every language; see SDK versioning.

Understanding Stripe API Versioning

Stripe uses date-based API versions (e.g., 2026-09-30.endive, 2025-08-27.basil, 2024-12-18.acacia). Your account’s API version determines request/response behavior.

Starting with the 2024-09-30.acacia release, Stripe releases new API versions monthly with no breaking changes. Twice a year, a new major release (for example, Basil) starts with an API version containing breaking changes. You can safely upgrade to any monthly release without updating your code.

Types of Changes

Backward-Compatible Changes (don’t require code updates):

  • New API resources
  • New optional request parameters
  • New properties in existing responses
  • Changes to opaque string lengths (e.g., object IDs)
  • New webhook event types

Breaking Changes (require code updates):

  • Field renames or removals
  • Behavioral modifications
  • Removed endpoints or parameters

Review the API changelog for all changes between versions. See API upgrades for the full upgrade guide.

Server-Side SDK Versioning

See Set a Stripe API version for your SDK for details on setting an API version in code.

Dynamically-Typed Languages (Ruby, Python, PHP, Node.js)

These SDKs offer flexible version control:

Global Configuration:

python
import stripestripe.api_version = '2026-09-30.endive'
ruby
Stripe.api_version = '2026-09-30.endive'
javascript
const stripe = require('stripe')('sk_test_xxx', {  apiVersion: '2026-09-30.endive'});

Per-Request Override:

python
stripe.Customer.create(  email="[email protected]",  stripe_version='2026-09-30.endive')

Strongly-Typed Languages (Java, Go, .NET)

These use a fixed API version matching the SDK release date. Don’t set a different API version for strongly-typed languages because response objects might not match the strong types in the SDK. Instead, update the SDK to target a new API version.

Best Practice

Always specify the API version you’re integrating against in your code instead of relying on your account’s default API version:

javascript
// Good: Explicit versionconst stripe = require('stripe')('sk_test_xxx', {  apiVersion: '2026-09-30.endive'});
// Avoid: Relying on account defaultconst stripe = require('stripe')('sk_test_xxx');

Stripe.js Versioning

See Stripe.js Versioning for details.

Stripe.js uses an evergreen model with major releases (Acacia, Basil, Clover, Dahlia, Endive) on a biannual basis.

Loading Versioned Stripe.js

Via Script Tag:

html
<script src="https://js.stripe.com/endive/stripe.js"></script>

Via npm:

bash
npm install @stripe/stripe-js

Major npm versions correspond to specific Stripe.js versions.

API Version Pairing

Each Stripe.js version automatically pairs with its corresponding API version. For instance:

  • Endive Stripe.js uses 2026-09-30.endive API
  • Acacia Stripe.js uses 2024-12-18.acacia API

You can’t override this association.

Migrating from v3

  1. Identify your current API version in code
  2. Review the changelog for relevant changes
  3. Consider gradually updating your API version before switching Stripe.js versions
  4. Stripe continues supporting v3 indefinitely

Mobile SDK Versioning

See Mobile SDK Versioning for details.

iOS and Android SDKs

Both platforms follow semantic versioning (MAJOR.MINOR.PATCH):

  • MAJOR: Breaking API changes
  • MINOR: New functionality (backward-compatible)
  • PATCH: Bug fixes (backward-compatible)

New features and fixes release only on the latest major version. Upgrade regularly to access improvements.

React Native SDK

Uses a different model (0.x.y schema):

  • Minor version changes (x): Breaking changes AND new features
  • Patch updates (y): Critical bug fixes only

Backend Compatibility

All mobile SDKs work with any Stripe API version you use on your backend unless documentation specifies otherwise.

Upgrade Checklist

  1. Review the API changelog for changes between your current and target versions
  2. Check the API upgrades guide for migration guidance
  3. Update server-side SDK package version (e.g., npm update stripe, pip install --upgrade stripe)
  4. Update the apiVersion parameter in your Stripe client initialization
  5. Test your integration against the new API version using the Stripe-Version header
  6. For each destination that receives snapshot events, review its configured API version. For webhook endpoints, follow webhook versioning. For every v2 snapshot event destination — including webhook endpoints, Amazon EventBridge, and Azure Event Grid destinations — inspect snapshot_api_version and, if it differs from the target, create and test a replacement destination because you can’t change it after creation. For a replacement webhook endpoint, save its new signing secret and configure the handler to accept both secrets during testing and cutover. After cutover, disable or delete the old destination to avoid duplicate delivery. Leave thin event destinations unchanged
  7. Update Stripe.js script tag or npm package version if needed
  8. Update mobile SDK versions in your package manager if needed
  9. Store Stripe object IDs in databases that accommodate up to 255 characters (case-sensitive collation)

Testing API Version Changes

Use the Stripe-Version header to test your code against a new version without changing your default:

bash
curl https://api.stripe.com/v1/customers \  -u sk_test_xxx: \  -H "Stripe-Version: 2026-09-30.endive"

Or in code:

javascript
const stripe = require('stripe')('sk_test_xxx', {  apiVersion: '2026-09-30.endive'  // Test with new version});

Important Notes

  • For supported event types, follow the migration guide to move from snapshot events to thin events. After migration, webhook payloads no longer depend on API version upgrades; API calls that retrieve the full event or related resource remain versioned.
  • Your webhook listener should handle unfamiliar event types gracefully
  • Test webhooks with the new version structure before upgrading
  • Breaking changes are tagged by affected product areas (Payments, Billing, Connect, etc.)
  • Multiple API versions coexist simultaneously, enabling staged adoption
  • For 72 hours after upgrading, you can roll back to your previous API version in Workbench

Source and attribution

Source:stripe/aiinskills/upgrade-stripeat commit08d371a

License: No license

Content belongs to its original authors. SourceWeft indexes it from a public repository.

Report or request removal

More from stripe/ai

Stripe Best Practices

stripe

Guides Stripe integration decisions across development and test environment planning (separate sandboxes vs the shared test mode sandbox), API selection (Checkout Sessions vs PaymentIntents), Connect platform setup (Accounts v2, controller properties), billing/subscriptions, tax and registrations (Stripe Tax, automatic_tax, product tax codes), Treasury financial accounts, integration options (Checkout, Payment Element), migrating from deprecated Stripe APIs, and security best practices (API key management, API key permissions, webhooks, OAuth). Use when planning, building, modifying, testing, or reviewing any Stripe integration, including choosing a development environment, accepting payments, building marketplaces, integrating Stripe, processing payments, setting up subscriptions, collecting sales tax, VAT, or GST, creating connected accounts, or implementing secure key handling.

Awaiting classificationOct 8, 2026

Metronome

stripe

Guides Metronome usage-based billing integration decisions — event ingestion (single and batch, idempotency, billable metrics), contract design (rate cards, overrides, dimensional pricing, products), invoicing lifecycle (grace periods, finalization, Stripe sync), credit and commit management (prepaid, postpaid, thresholds, auto-recharge), and Stripe integration (arrears invoicing, tax providers, line item limits). Use when building, modifying, or reviewing any Metronome integration — including ingesting usage events, creating contracts or rate cards, managing credits and commits, configuring invoicing, or syncing invoices with Stripe Billing.

Awaiting classificationOct 8, 2026

Connect Required Verification Information

stripe

Use this skill when the user asks what information a Stripe Connect connected account must provide for verification, onboarding, KYC, or account requirements; when they need to compare requirements between connected-account setups; or when they ask which verification fields, documents, or business details are required for a particular platform country, account country, business type, dashboard, service agreement, or capability.

Awaiting classificationOct 8, 2026

Connect Recommend

stripe

Recommends a Stripe Connect configuration and charge pattern from a business description or codebase scan.

Business & FinanceOct 8, 2026