01
Detect
Understand the provider change at the API, SDK, schema, or contract level.
AUTOMATED API & SDK MIGRATION
The APIs you depend on change.
Fettler changes the code.
Fettler maps an API, SDK, or provider change through your codebase, identifies the affected paths, generates the migration, verifies the result, and delivers a reviewable pull request.
Not just the patch.
The evidence for why it should be there.
Built for engineering teams that depend on third-party APIs, SDKs, and platforms.
acme/payments-sdk
PR open
Migrate charge() → charges.create()
#4821
src/api/client.ts
+12−9
@@ -14,7 +14,7 @@ export async function charge(order) {
14 const pay = new Payments(process.env.KEY);
15− await pay.charge(order.total, 'usd');
15+ await pay.charges.create({ amount: order.total });
16 return { ok: true };
verified
6 files · 1 unresolved
opened by Fettler
THE PROBLEM
When an API changes, the hard part is not writing code.
The hard part is knowing what actually needs to change.
A provider changes an endpoint, authentication flow, SDK method, request schema, or response contract. Your engineers have to work out what changed upstream, where it is used, what sits behind internal wrappers, what else depends on it, what can safely change, what must remain untouched, and whether the migration is actually complete.
Searchfinds text.
Coding agentsgenerate code.
Mendpointreasons about the change itself and its impact across the system.
MEET FETTLER
External change, automatically mended.
Fettler turns third-party software changes into evidence-backed migration work.
02
Map
Resolve that change through the Change Graph to the code paths that depend on it.
03
Migrate
Generate the required edits using the appropriate migration strategy for each affected path.
04
Verify
Run the available build, test, type, contract, graph, and policy checks.
05
Review
Deliver a pull request showing what changed, why, what was verified, and what remains uncertain.
THE MENDPOINT CHANGE GRAPH
Know what depends on what before changing anything.
Mendpoint builds a persistent representation of how your software fits together, connecting provider changes to the software that depends on them. When something changes upstream, Fettler traverses those relationships instead of asking a model to rediscover the entire system from scratch.
Every relationship carries its provenance and evidence. And when the graph is incomplete, Mendpoint says so.
“No impact found” is not the same as “no impact found with insufficient coverage.”
That distinction matters when production software is on the other side of the answer.
DEPENDENCY PATH
Provider change
API endpoint
SDK method
internal wrapper
application function
service
test
EVIDENCE, NOT ASSERTION
The PR contains more than the fix.
It contains the proof.
The goal is not to make engineers trust an AI agent. The goal is to give engineers enough evidence to make a good review decision themselves.
Review first. Human stays in control.
A MENDPOINT MIGRATION CARRIES
what changed upstream
why this repository is affected
the dependency path that led to the code
the proposed edit
verification results
graph and test coverage
unresolved ambiguity
remaining uncertainty
COMPLETION ASSURANCE
Agents should not grade their own homework.
A migration can pass every test the implementing agent thought to run and still be incomplete. Mendpoint separates doing the work from deciding whether the work is done.
Fettler performs the migration.
A separate validator checks the result against an independent standard of completion, established before implementation begins.
If uncertainty cannot be resolved automatically, it is surfaced for human judgment.
The agent does not get to declare victory simply because its local checks pass.
THE ASSURANCE LOOP
Define what complete means
Perform the migration
Validate independently
Find missing work
Repair
Revalidate
Ready for human review
UNCERTAINTY
Built for uncertainty, not hidden behind it.
Software systems are messy. Static analysis misses runtime behavior, tests are incomplete, dependencies are indirect, and internal abstractions hide provider usage. Mendpoint distinguishes between what it knows and what it does not — and that uncertainty influences how aggressively the system acts.
Observed
Inferred
Ambiguous
Stale
Conflicting
Unknown
MISSIONS
From one API change to a migration campaign.
A provider change rarely affects only one line of code. It may touch multiple functions, packages, services, repositories, or teams — so Fettler treats the migration as a Mission.
provider change
repository state
graph version
previous decisions
verification evidence
open exceptions
completed work
The next step does not have to start from zero.
REGAUGE
Once Mendpoint earns your trust on external change, ReGauge looks inward.
Fettler starts with changes coming from outside your system. ReGauge applies the same Change Graph, evidence, verification, and completion architecture to the changes you need to make inside it.
Instead of treating a modernization as one enormous coding-agent session, ReGauge preserves the state of the migration across stages, decisions, human interventions, and verification cycles.
FETTLER
earns the trust.
REGAUGE
expands it.
DESIGNED FOR WORK SUCH AS
Framework upgrades
Runtime migrations
Internal SDK migrations
Architecture transitions
Long-running legacy modernization
WHY NOT JUST USE A CODING AGENT?
Better models should make Mendpoint better.
Coding agents are becoming excellent at generating and modifying code, and Mendpoint assumes they continue getting much better. That is not the problem we are trying to own. Mendpoint is building the intelligence around the model: what changed, what depends on it, what must be preserved, what evidence exists, what remains unknown, and what must be true before the migration is complete.
COMPOUNDING
The next migration should benefit from the ones that came before it.
Every migration leaves behind more than merged code: what depends on what, which strategy worked, what the reviewer changed, where the graph was wrong, what verification caught, and how that organization prefers changes to be made.
graph corrections
migration recipes
retrieval and routing
tenant memory
evaluations
Designed around your existing engineering workflow.
Mendpoint is not designed to silently rewrite production. The output is reviewable engineering work, and your team remains responsible for approval.
Git repositories
pull requests
build systems
tests
code review
engineering policy
deployment controls
The objective is not to replace your engineering process. It is to remove the repetitive migration work inside it.
Your repository is not a prompt.
Mendpoint is being built around explicit system boundaries rather than trusting model behavior to enforce them. Customer data and organization-specific learning remain governed by the permissions under which they were collected.
tenant isolation
scoped repository access
controlled secrets
policy-bound execution
sandboxed execution
explicit external-model rules
DESIGN PARTNERS
Start with one real migration.
Give us one API or SDK change your team would otherwise have to migrate manually.
One real change. One real repository. Measurable result.
WE WILL ESTABLISH
what changed
what code is affected
what migration is required
what can be verified
what still requires human judgment
You review the result. Then we decide together whether Mendpoint deserves the next migration.
FAQ
Questions engineers ask first.
What is Fettler?
Fettler is Mendpoint’s product for third-party software change. It takes an API, SDK, provider, or contract change and turns it into mapped impact, proposed migration work, verification evidence, and a reviewable pull request.
What is ReGauge?
ReGauge applies Mendpoint’s migration infrastructure to internal software change such as framework upgrades, runtime migrations, architecture transitions, and legacy modernization.
Does Mendpoint automatically merge code?
The product is designed around review-first workflows. Mendpoint proposes and verifies changes; the customer retains approval authority.
How does Mendpoint know what code is affected?
Mendpoint uses the Change Graph to represent relationships between provider changes, APIs, SDK methods, internal abstractions, application code, services, schemas, tests, and other software entities.
What happens if Mendpoint is not sure?
Uncertainty should be surfaced rather than hidden. Incomplete coverage, ambiguous relationships, conflicting evidence, and unresolved verification can prevent a migration from being represented as complete.
How is this different from a coding agent?
A coding agent is primarily an implementation engine. Mendpoint focuses on the migration system around that implementation: change understanding, impact representation, persistent context, verification evidence, completion criteria, and learning from prior migration outcomes.
Does customer code train shared models?
Customer-specific data and learning should only be used according to the customer’s applicable permissions and governance. Organization-specific preferences can remain tenant-scoped rather than automatically becoming shared model training data.
What do you need to start?
A concrete API, SDK, or provider change and a repository where your team has to absorb that change.
The next API change should not become another migration project.
Give Fettler one real change. We’ll show you what it touches, what needs to change, what we can verify, and what still requires your judgment.