Conclusion
Read on their own, the API Sync screens look like separate tools. They are not. They are the stages of one loop, and the loop is the product.
The loop, end to end#
A change starts at a provider. On the Partner Provider side, an onboarded partner publishes it through the Provider Console, and it lands in API Versions as a structured record. For providers who have not onboarded, API Sync pulls the same kind of record from public specs and changelogs instead. Either way, the Provider Catalog shows how each provider is covered.
On the Consumer side, Integration Inventory has already scanned your repositories and knows which applications call which providers, down to the call site. When a change matches your detected usage, or when a standing best-practice rule flags outdated code, the affected code becomes a Sync PR with evidence attached. If you have set up a Verified PR for that application, API Sync builds and deploys the patched branch and runs your test against it, and the result shows up in Verified Runs. The Dashboard sits over all of it and answers the one question that matters: is everything in sync?
Each screen hands off to the next. Scan feeds the inventory, the inventory feeds the PRs, the PRs feed the runs, and the runs feed the badge that makes a PR safe to merge.
The principles that hold across every screen#
Nothing is fabricated. A scan that cannot run says why. A finding is written only from real code. A test run records a verdict only from a real execution. A provider found in your code but not in the registry is labeled exactly that. Where a number is unknown, the screen shows a dash, not a zero.
A human stays in control. API Sync opens branches and pull requests. It does not merge them. Reviewers see the change, the evidence, and the run result, and they decide. The only automated merge is an opt-in path for low-risk changes, off by default.
Providers and consumers keep their boundaries. A partner publishes structured facts about their own change and never sees consumer code. A consumer gets the fix applied to their code and never has to hand over their repository to the provider. API Sync sits between them and does the matching.
The work is scoped and contained. Every request is authenticated and scoped to one company. Long-running jobs run in the background with bounded concurrency, and a reaper cleans up anything a crash leaves behind. Repositories are read as tarballs, secrets are never stored as values, and webhooks are signed.
What is live and what is still coming#
The screens described in these pages are wired to a real backend, not mock fixtures. Scanning, AI analysis, PR generation against real GitHub repositories, the provider registry, change publishing, and verified test runs through Newman and OpenAPI all run today.
One piece is explicitly not finished yet: the Runtime evidence tab on an integration’s detail page. It will show observed traffic through the ATA Gateway to confirm whether deprecated usage is actually on your hot path. Until that lands, the tab says so plainly rather than showing a stub, which is the same honesty rule that governs the rest of the product.
That is API Sync: detect the change, find the affected code, open the fix, prove it works, and keep a human in the loop the whole way.