API Sync

APIs break their consumers. A provider like Stripe deprecates a field, a webhook payload changes shape, an SDK method gets renamed, and somewhere in your codebase a call site quietly stops doing what it used to. You usually find out in production.

API Sync exists to close that gap. It watches the external APIs your applications depend on, detects when one of them changes, finds the exact code affected across your repositories, and opens a reviewed pull request that brings your usage current. It never merges for you. The goal is that “is everything in sync?” has an answer you can trust at a glance.

The feature has two sides, and the sidebar is split along that line.

Consumer#

This is the side most teams live on. You connect your GitHub organization, scan your Technical Applications, and API Sync tells you which providers each app talks to and whether that usage is outdated or risky. When a provider ships a change, the affected code turns into a Sync PR with evidence attached.

The Consumer screens are:

• Dashboard: the “is everything in sync?” answer, plus what API Sync is watching for the selected team.
• Integration Inventory: every Technical Application and the provider integrations detected inside each one. Scan happens here.
• Sync PRs: the pull requests API Sync has generated for your team to review and merge.
• Verified Runs: the test runs behind Verified PRs, one row per run, with an honest pass or fail.
• Provider Catalog: the external providers API Sync supports and how each one is kept current.

Partner Provider#

This side is for providers who have onboarded as partners. Instead of API Sync inferring your changes from public specs and changelogs, you publish them yourself. A partner authors a change once, and API Sync turns it into validated PRs across every consumer using that provider, without ever reading the consumer’s source code.

The Partner Provider screens are:

• Provider Console: the partner’s home. Adoption numbers, published changes, and the entry point for publishing a new one.
• API Versions: every version a partner publishes, the migration path to it, and where each record came from.

The shared machinery#

Every screen in API Sync sits on the same foundation, so the non-functional notes on each page point back here.

Frontend. API Sync is a federated microfrontend remote (./ApiSyncRoutes) mounted at /api-sync/* inside the API Governance web app. Pages are lazy-loaded React 18 components using MUI v6. Data goes through a single RTK Query slice (apiSyncApi) that talks to the NestJS backend under /v1/api-sync/*. Responses come back as an encrypted envelope and are unwrapped client-side before any component reads them.

Backend. The api-sync module lives in governance-api-nest. Every route is authenticated with a JWT and scoped to the caller’s company, so one company never sees another’s inventory, PRs, or runs.

Long-running work runs as background jobs. Scanning a repo, analyzing an integration with AI, and generating a PR all take time, so the backend inserts a job row, kicks off the work as a fire-and-forget task, and returns a jobId immediately. The frontend polls GET /v1/api-sync/jobs/:id every five seconds and refreshes its list when the job reaches a terminal state. AI-heavy jobs run behind a small counting semaphore (two at a time by default) so concurrent agent loops stay bounded. A cron reaper runs every five minutes and fails any job whose heartbeat has gone stale after a process restart, so a crash never leaves a screen polling a job that will never finish.

GitHub access is a per-company token. The Personal Access Token lives in the company’s GitHub integration config and is read through a shared credential resolver. Scanning reads the repo as a downloaded tarball rather than cloning it, and PRs are opened through the GitHub Git Data API. If no token is configured, the affected screens say so plainly instead of failing silently.

Honesty is a rule, not a preference. API Sync never fabricates a result. A scan that cannot run reports why. A test run only records “passed” or “failed” from a real execution, and anything else is a failure with the real error. Providers detected in your code but not yet in the registry are labeled exactly that, not hidden.

Read the Consumer and Partner Provider pages for what each screen does and how it behaves. The Conclusion ties the loop together and notes what is live today versus what is still coming.