How it works

From API change to verified pull request.

Five stages run for every change that touches your code. Each one has to succeed before the next begins, and a run that cannot prove its change stops without opening anything.

  1. Stage 1: Detect

    Identify API changes that matter to your repository.

    Mantle reads Stripe’s published changelog and API specification, turns each entry into a structured record, and keeps only the changes your code actually calls.

    Stripe changelogEndive release
    • Removes the payment method types parameter from Checkout SessionsNot used
    • Unifies the billing cycle anchor format across Subscriptions and InvoicesUsed in this repository
    • Makes Payment Evaluation signal scores nullableNot used
    • Renames the countries filter to country on Financial Connections SessionsNot used
  2. Stage 2: Understand

    Trace the change through the codebase and identify the affected paths.

    Your repository is parsed, not searched. Mantle follows your Stripe client through wrappers to the exact call sites that pass the changed parameter.

    Call graph5 call sites · 3 affected

    src/lib/stripe.ts Client

    • src/billing/change-plan.tsAffected
    • src/billing/preview.tsAffected
    • src/billing/resume.tsAffected
    • src/billing/signup.tsClear
    • src/checkout/session.tsClear
  3. Stage 3: Migrate

    Write the new code in a disposable workspace.

    Mantle rewrites each affected call the way the new API expects, anchored to your exact lines. An edit that does not match the file is rejected rather than guessed. The workspace is deleted when the run ends.

    Workspacerun 7f3a · disposable
     subscription_details: {   items: [{ price }],−  billing_cycle_anchor: anchor,+  billing_cycle_anchor: {+    type: 'timestamp',+    timestamp: anchor,+  }, },

    Anchored to src/billing/preview.ts:13Edit applied · +4 −1

  4. Stage 4: Verify

    Run typechecks, tests, linting and builds.

    Your own scripts, from your own package.json. A failing check stops the run, and a run where nothing could execute is never called verified.

    Verificationyour package.json scripts
    • installPassed
    • typecheckPassed
    • lintPassed
    • test212 passed
    • buildPassed
  5. Stage 5: Open

    Create a pull request only when the migration is validated.

    The pull request explains the API change, why your repository is affected, what changed and every check result. Your team reviews it and decides.

    Pull request #214

    Update Stripe integration: billing_cycle_anchor type changed

    • ## API change
    • ## Why this repository is affected
    • ## What Mantle changed
    • ## Verification
    VerifiedWaiting for your review

Illustrations use a sample repository

Try it

Review a diff, not a changelog.

One real Stripe change, run through a sample repository. Step through the stages, open any file, or see what happens when a check fails.

acme/paymentsSample repository · simulated runStage · 1/5

01 · API change

Stripe changed how billing cycle anchors are sent.

Three calls now take an object where they took a string. Code that still sends a string, such as ’now’, no longer matches the API.

Release
Endive · Sept 2026
Breaking
Yes · 1 of 28
Recorded as
field_type_changed
Read from
Stripe’s changelog
Stripe changelogEndiveBreaking

Unifies the billing cycle anchor format across Subscriptions and Invoices

  • subscriptions.update()'now' | 'unchanged'{ type }
  • subscriptions.resume()'now' | 'unchanged'{ type }
  • invoices.createPreview()subscription_details.billing_cycle_anchor'now' | 'unchanged' | timestamp{ type, timestamp }
What changes in a request
−billing_cycle_anchor: 'now'+billing_cycle_anchor: { type: 'now' }

Simulated run on a sample repository. The Stripe change is real; the code and results are illustrative.Stripe’s changelog (opens in a new tab)

Run it on your own repository.

How it works · Mantle