Autonomous API migrations
APIs change.Your code should keep up.
Browniie watches the changelogs and release notes for the APIs you depend on. When one breaks your integration, it writes the fix, runs your tests, and opens a pull request.
$ browniie watch 6 providers · 3 repositories ! stripe v4.1 → v5.0 breaking change release notes: "payment_method_types is removed; use a payment method configuration instead." ✓ resolved 14 call sites across 3 files ✓ migration written src/payments/checkout.ts +2 -2 src/payments/webhooks.ts +1 -1 src/billing/customer.ts +1 -1 ✓ npm test 23 passed, 0 failed 41.2s ✓ opened #1842 · stripe/v5-migration 1 provider changed. 1 pull request opened. $
The problem
Nobody reads the changelog.
Every provider ships on their own schedule, in their own format, with their own idea of how much notice is enough. Plenty of breaking changes never get a version bump at all. They arrive as one sentence in a release note. Tracking that across every vendor is real work, and it is nobody's job, so it does not get done until something breaks in production.
- Most products depend on dozens of external APIs. Nobody owns watching them.
- Deprecation notices arrive in newsletters, RSS feeds and release-note footnotes.
- New capabilities ship quietly. Existing integrations never pick them up.
- Semver only helps when the provider bumps the version. Often they just edit the docs.
- StripeBreakingCheckout session options restructured
- TwilioDeprecatedProgrammable Chat reaches end of life
- ShopifyBreakingREST Admin endpoints sunset for GraphQL
- PlaidAddedCursor-based transaction sync
- SlackDeprecatedLegacy workspace tokens retired
- Auth0BreakingRefresh token rotation now mandatory
- SegmentAddedBatched identify calls
- SendGridDeprecatedv2 mail send removed
Illustrative.
How it works
From their release to your branch.
Browniie does the first three. You do the fourth.
We read the release notes
Every changelog, migration guide and SDK release for your providers, parsed the day it ships. Prose included. Most breaking changes are announced in a sentence, not a version bump, so a spec diff alone misses them.
stripe · "payment_method_types is removed"
We find the affected code
The change is resolved against your repositories and narrowed to the call sites that actually touch it. A reference graph, not a grep, so aliased imports and wrappers count.
14 usages · 3 files · 1 service
The agent makes the change
Not a suggestion, not a TODO. It edits the files, follows the migration path the provider documented, and runs your suite. If it fails, it iterates before anything reaches you.
payment_method_types: ["card"],
payment_method_configuration: PMC_ID,
You review a pull request
Scoped to one provider, with the sentence that triggered it and the reasoning behind each edit. Merge it or don't.
#1842 opened · awaiting review
Why now
This wasn't buildable until recently.
Detecting that an API changed is not the hard part. Diffing two specs does that. The hard part is making the change inside a codebase you have never seen, and that only became practical recently.
Agents can read code now
Not autocomplete. Agents that navigate a repository, hold a multi-file change in context, run the suite, and read the failure well enough to try again. That is roughly two years old.
The plumbing already shipped
Scoped repo access, sandboxed execution, CI, human review. Everything needed to make an automated code change safe is already standard.
The connection doesn't exist
No provider can reach the codebases that depend on them. They publish a changelog and hope it gets read. That gap is what Browniie fills.
API providers shouldn't just announce changes.
They should help their customers ship them.
Try it on your next breaking change.
We're working with a first group of teams before opening it up. If you maintain more than a handful of API integrations, leave your email.