Sync PRs
Sync PRs is the payoff screen. It lists the pull requests API Sync has generated for your team, each one a fix delivered as a real GitHub PR with evidence attached. API Sync never merges automatically. A human reviews and merges, the same as any other PR.
What it does#
One table, one row per PR. Each row shows the PR number (linked to GitHub when the PR exists), the title, the provider, what triggered it, how many files it touches, when it was opened, its risk, and its current state. States run from queued and generating through open, in-review, and validating, to merged, closed, or failed.
Two reasons a PR exists. The Trigger column tells you why:
- Change-driven means a provider shipped a change and a partner or platform migration pack matched your usage. This is the migration case.
- Usage-review means your implementation was outdated or risky against best-practice rules, independent of any single change. This is the standing review case.
An evidence drawer. Clicking a row opens a drawer with the full picture: the change type and trigger as chips, the risk, what changed (file count and repositories), a plain explanation of what triggered it, and the details (branch, opened date, validation result). A failed PR shows its error in the drawer. A “Open on GitHub” button takes you to the PR itself.
Refresh from GitHub. Each row has a refresh action that re-syncs that PR’s state from GitHub, so a merge or close done outside API Sync shows up here.
How it behaves#
We never merge for you. This is stated on the screen and enforced by the model. API Sync opens branches and PRs; merging stays with your team. The one exception across the product is an opt-in auto-merge for low-risk changes, which is off by default and not something this screen does on its own.
PRs are real, and so are the failures. A PR row corresponds to an actual pull request opened through the GitHub Git Data API using the company’s token. When PR generation produces zero edits, the job fails with the agent’s explanation and no empty PR row is left behind. A failed PR keeps its error so you can see what went wrong rather than guessing.
Honest empty state. With no PRs yet, the screen says so instead of showing an empty grid with no explanation.
Data flow. The list is useListPrsQuery over GET /v1/api-sync/prs. The refresh action is a mutation against POST /v1/api-sync/prs/:id/refresh that invalidates the PR and inventory caches so both screens reflect the new state. PRs themselves are created from the integration detail page’s findings or generated from provider changes, and they land here once they exist.