Get every customer
off the old API.

When your API changes, Driftfix opens a pull request in each customer’s repo that updates their code. Their tests run on it first. It’s free for developers.

See the demo Talk to us

For the team that has to turn off v1.

See an example
01/03

You ship v3 and write a migration guide. A year later, half your customers are still on v2 and you can’t turn it off.

We read your guide, find the code in each customer’s repo that uses the old API, and change it the way the guide says to.

Their tests run on the change. If it passes, they get a pull request. Someone on their team reviews it and merges it.

How it works

What happens after you ship a breaking change.

Send us the changelog entry or migration guide, or tell us where you publish them. We try the migration on your sample code before release. Then we open a pull request in every repo that has our GitHub app and still uses the old API.

Become a design partner
01.

We read your guide

Every edit links back to the part of your guide it came from. If the guide doesn’t cover something, we leave that code alone and say so in the PR.

02.

We run their tests

The patch runs against the repo’s own test suite in a sandbox with no secrets and no network. The PR shows the exact command and how many tests passed.

03.

They get a pull request

It only touches code that uses your API. We never push to their main branch and never merge anything. Someone on their team does that.

Privacy

Your code stays yours.

It’s the first thing engineering and security teams ask, so here’s exactly how it works. Driftfix only touches the code that needs changing, for as long as one job takes. API companies see totals across all their customers, and you decide whether they see you at all.

Deleted after every job

We clone your repo into a throwaway workspace for one job, then delete it. Your code is never stored on our side.

Only the code that needs changing

The model sees the files that call the changed API and what they import. The rest of your repo never leaves the workspace.

Tests run sealed off

A fresh container with no secrets, no tokens and no network while your tests run. It’s destroyed afterwards.

You choose what they see

By default an API company sees totals with small numbers hidden. Name a repo if you want credit, or leave it out of their counts entirely.

What an API company sees

Totals across all their customers. That’s it.

Code, diffs, file paths and test output are never shown to an API company, whatever your settings.

See it in the demo
ChangeAffectedMigratedNamed
Charges v1 sunset41284%5 opted in
Webhooks v226841%2 opted in
Node SDK 5.013327%<5
Your reposCounted with your name hidden, or not counted at all. Your call.
Example

Pick a change to see the pull request a customer would get.

Open

Pricing

Developers don’t pay. API companies do.

Developers install the app and get fixes when an API they use changes. API companies pay because their customers end up on the new version without anyone chasing them.

Developers

Free

Install the GitHub app on the repos you want covered. That’s the whole setup.

  • One pull request per upstream change
  • Your tests run before you see it
  • Pushes only to its own branch
  • Never merges anything
  • Asks for repo contents and pull requests, nothing else
Get early access

API companies

Pilotfree for design partners

For the people responsible for getting customers onto the new version.

  • Try a migration on your sample code before release
  • Delivered to every repo with the app that uses you
  • See who has migrated, who’s stuck, and why
  • Counts only, never your customers’ code
  • We set it up with you, by hand
Become a design partner
FAQ

Questions we get a lot.

Do developers pay anything?

No. The API company pays. You can install the app whether or not they’re a customer of ours, and you get the same pull requests either way.

Isn’t this what Dependabot does?

Dependabot and Renovate bump the version number. If the new version changes how you call it, your code still breaks. We fix that part. You can keep using both.

What if the tests fail?

You get a draft pull request with the failing output so you can see what went wrong. If we can’t find a way to run your tests, the PR says it’s untested in the first line.

What does the API company see about my repo?

Numbers: how many repos were affected, how many merged, how many are stuck and roughly why. They don’t see your code, your diffs, or your file paths. They only see your repo’s name if you turn that on, and you can leave a repo out of their counts entirely.

Could an API company use this to sneak something into my code?

We treat their guide as text to read, not instructions to follow. Every patch is checked before it goes anywhere. It can only change files that use their API, and it can’t touch CI config, workflows, install scripts, or .env files.

What languages do you support?

TypeScript, JavaScript and Python, on GitHub. We’ll add more once those work really well.

Got a deprecation
coming up?

We’re looking for a few API companies to try this on their next breaking change. Tell us what it is and when it ships.

Get in touch
Get in touch

Tell us what you’redeprecating next.

or email