Updatesapi-stripe

Stripe API: 100 Breaking Changes in Account, Account Links

14a40f813acc → ed93b94259c5Verified February 22, 2026

```mdx

TL;DR

  • All 100 changes in this diff are classified as breaking, meaning no gradual migration path is implied — every affected integration requires review before the next deployment.
  • The schema restructuring centers on a deeply nested pricing field within Invoice line items, specifically the anyOf subschemas for BillingBilling* types, which affects how pricing data is resolved across subscription flows.
  • Twenty-four endpoints spanning account management, bank accounts, capabilities, people/persons, external accounts, Apple Pay domains, and application fees are all touched by the same underlying schema change.
  • The BankAccount → Customer → subscriptions → latest_invoice → lines → pricing resolution chain is the common thread — any code that traverses this path in response objects may encounter structural differences.
  • Clients relying on generated SDK types or OpenAPI-derived models will likely see compile-time or runtime failures if models are not regenerated against the updated spec.

    • ---

    Editor's Note: We want to be direct: this is not a routine patch. The breadth of 100 breaking changes across a single commit — all tracing back to a schema restructuring of the pricing anyOf subschemas on invoice line items — signals a deliberate, coordinated API model refactor rather than an incremental feature addition. This fits a pattern we've observed in Stripe's OpenAPI spec history where pricing model expansions (such as the introduction of multi-currency or usage-based billing primitives) ripple upward through deeply nested response schemas. Our practical tip: regenerate your OpenAPI client immediately in a non-production environment and run your full integration test suite against the new spec before promoting any changes — the nested path depth here makes manual inspection unreliable.

    ---

    What Changed

    Breaking

    All 100 changes are breaking. They share a common schema modification: the pricing field within Invoice.lines.data[].pricing has had its anyOf subschema composition altered. Specifically, subschema #1 (previously or newly referencing a BillingB* type — truncated in the diff as BillingB) has changed in a way that is not backward-compatible with the prior shape.

    This change propagates through every endpoint that can return a BankAccount object with an expanded customer, because the Customer object embeds subscriptions, which embed latest_invoice, which embeds lines, which embed pricing. The affected endpoints include:

    Account & Identity endpoints

  • /v1/account — 2 breaking changes
  • /v1/account_links — 2 breaking changes
  • /v1/account_sessions — 2 breaking changes
  • /v1/accounts — 4 breaking changes
  • /v1/accounts/{account} — 6 breaking changes
  • /v1/accounts/{account}/capabilities and /v1/accounts/{account}/capabilities/{capability}
  • /v1/accounts/{account}/people, /v1/accounts/{account}/people/{person}
  • /v1/accounts/{account}/persons, /v1/accounts/{account}/persons/{person}
  • /v1/accounts/{account}/login_links
  • /v1/accounts/{account}/reject

    • Bank Account & External Account endpoints

  • /v1/accounts/{account}/bank_accounts — 4 breaking changes, including changes to both the root response schema (/anyOf[subschema #1: BankAccount]/...) and the error/source path
  • /v1/accounts/{account}/bank_accounts/{id} — multiple breaking changes across both response and error source paths
  • /v1/accounts/{account}/external_accounts
  • /v1/accounts/{account}/external_accounts/{id}

    • Apple Pay & Application Fee endpoints

  • /v1/apple_pay/domains and /v1/apple_pay/domains/{domain}
  • /v1/application_fees, /v1/application_fees/{id}, /v1/application_fees/{id}/refund, /v1/application_fees/{id}/refunds
  • /v1/application_fees/{fee}/refunds/{id}

    • Two distinct schema paths are affected within each endpoint:

    1. error/source/anyOf[subschema #1: BankAccount]/... — the error response object, meaning error payloads that include an expanded source bank account are also structurally changed.

    2. /anyOf[subschema #1: BankAccount]/... — the primary success response object for endpoints that return BankAccount directly.

    ---

    Who's Impacted

    If you use Stripe's OpenAPI spec to generate typed API clients (e.g., via openapi-generator, kiota, or custom tooling), you will likely encounter compilation errors or silent type mismatches until models are regenerated from the updated spec at commit ed93b94259c5.

    If you expand the customer object on BankAccount responses and then traverse into subscriptions[].latest_invoice.lines.data[].pricing, your deserialization logic may fail or return unexpected null values depending on how your client handles anyOf schema changes.

    If your integration handles error responses that include an expanded source field of type BankAccount, the error.source schema has also changed — meaning error-handling code that inspects pricing-related fields on the source object is equally affected.

    If you operate a Connect platform and call /v1/accounts/{account}/bank_accounts or /v1/accounts/{account}/external_accounts with customer expansion enabled, both the success and error response shapes for those endpoints have changed.

    ---

    Action Checklist

  • ☐ Pull the latest Stripe OpenAPI spec from commit ed93b94259c55782b8b04e01f4ffdaa2872e9bcd into your local toolchain
  • ☐ Regenerate all OpenAPI-derived client models and compare the diff against your current generated code
  • ☐ Search your codebase for any access to invoice.lines.data[*].pricing and audit the field access patterns
  • ☐ Identify all locations where BankAccount.customer is expanded and the resulting Customer object is traversed into subscriptions
  • ☐ Review error-handling code that inspects error.source when the source is a BankAccount — the schema for this path has changed
  • ☐ Check whether your integration calls any of the 24 affected endpoints with expand[] parameters that include customer, subscriptions, latest_invoice, or lines
  • ☐ Run your full integration test suite against the updated spec in a staging environment before any production deployment
  • ☐ Update any JSON Schema validators or contract tests that reference the pricing anyOf subschemas on invoice line items
  • ☐ Review Stripe SDK release notes for your language (Python, Ruby, Node, Java, Go, PHP, .NET) to confirm whether an updated SDK version has been published against this spec version
  • ☐ If using a pinned Stripe SDK version, check whether that SDK version reflects the pre- or post-change schema
  • ☐ Audit any webhook handlers that deserialize Invoice objects — if your handler expands line items and reads pricing, it may be affected
  • ☐ Verify that your Connect platform's account onboarding flows (which call /v1/account_links and /v1/account_sessions) are not broken by the error response schema change
  • ☐ Test the /v1/accounts/{account}/capabilities and /v1/accounts/{account}/capabilities/{capability} endpoints explicitly, as they carry 6 breaking changes across the {account} resource group
  • ☐ Confirm that Apple Pay domain registration flows (/v1/apple_pay/domains) still behave as expected, since these endpoints are included in the affected set
  • ☐ Validate application fee refund flows (/v1/application_fees/{id}/refunds, /v1/application_fees/{fee}/refunds/{id}) in your test environment
  • ☐ Check /v1/accounts/{account}/people and /v1/accounts/{account}/persons endpoint responses if your integration reads person objects with expanded bank account data
  • ☐ Document the spec version transition (14a40f813acc → ed93b94259c5) in your internal changelog so downstream teams are aware of the boundary
  • ☐ If you maintain a mock Stripe server for local development, update its schema definitions to reflect the new pricing anyOf structure
  • ☐ Coordinate with any third-party integrators or partners who consume your Stripe-proxied data to ensure they are aware of the structural change in pricing fields
  • ☐ Set up a canary deployment or feature-flagged rollout if your production traffic volume makes a hard cutover risky

    • ---

    Verification

  • Commit ed93b94259c5 — Stripe OpenAPI GitHub repository, direct commit reference: [https://github.com/stripe/openapi/commit/ed93b94259c55782b8b04e01f4ffdaa2872e9bcd](https://github.com/stripe/openapi/commit/ed93b94259c55782b8b04e01f4ffdaa2872e9bcd)
  • Stripe API Spec Diff — Full comparison between base commit 14a40f813acc3a6a8f75bf80b2c06955f5d574d7 and head commit ed93b94259c55782b8b04e01f4ffdaa2872e9bcd: [https://github.com/stripe/openapi/compare/14a40f813acc3a6a8f75bf80b2c06955f5d574d7...ed93b94259c55782b8b04e01f4ffdaa2872e9bcd](https://github.com/stripe/openapi/compare/14a40f813acc3a6a8f75bf80b2c06955f5d574d7...ed93b94259c55782b8b04e01f4ffdaa2872e9bcd)

    • Last verified: 2026-02-22T06:40:28Z

    ```

    📎 Sources

    Stripe API: 100 Breaking Changes in Account, Account Links | Brief Stack