Integration Inventory
Integration Inventory is where the graph gets built. It lists every Technical Application across your platform and, under each one, the external-provider integrations found in its code. Scanning starts here, and each integration links to a detail page where findings turn into pull requests.
What it does#
A flat table of Technical Applications. Each row is one application, which carries its own git repository. A row shows the app’s name and type, the repo it maps to, its tech stack, the Business Application(s) it belongs to, how many integrations were detected, the highest risk among them, its scan status, and its Verified PR state. Rows with integrations expand to reveal them.
Scanning. The Scan button on a row reads the app’s repository and detects which providers it calls. Scanning is deterministic and uses no AI: the backend downloads the repo as a tarball, walks the files, matches them against a set of provider detection rules, reads declared SDK versions from the manifest, and records each detected integration. Integrations that vanished from the code since the last scan are removed, so the inventory tracks the code rather than drifting from it.
Per-integration analysis. Expanding a row lists its integrations, each with the SDK and version, the API version, the coverage source, and a risk chip. The Analyze button runs an AI pass on a single integration that cross-references the real code against what API Sync knows about that provider, then writes findings.
The integration detail page. Clicking an integration opens a tabbed detail view:
- Overview shows the implementation facts (SDK, API version, usage, files touched, coverage) and the exact call sites, listed as
path:line. - Findings lists what analysis turned up, each classified as outdated, risky, or better-practice. An open finding offers “Create PR” and “Dismiss.”
- Runtime evidence is reserved for observed traffic through the ATA Gateway and is marked coming soon.
- Related PRs lists the pull requests tied to this integration, with links to GitHub.
Verified PR setup. Each row has a Verified PR control that opens a drawer for configuring the dedicated branch, the deployment base URL, the deploy webhook, and the test artifact (a Postman collection with optional dataset and environment, or an OpenAPI spec). This is what powers Verified Runs.
How it behaves#
Server-side search, filters, and pagination. The search box, the business-application filter, the scan-status filter, and the has-integrations filter are all resolved by the backend, not in the browser, so the table stays responsive over a large inventory. Typing in the search box is debounced by 400 milliseconds so each keystroke does not fire a request. The footer count reads the total from the server and notes when a filter is active.
Live job progress. Starting a scan or an analysis returns a jobId. The page polls that one active job every five seconds, shows its stage and progress bar while it runs, and refetches the table when it reaches a terminal state so the new integrations and scan status appear on their own. If the job fails, the error is shown inline.
GitHub gating, stated plainly. If the company has no GitHub token configured, a warning explains that applications cannot be scanned yet and points to Company Settings. The Scan button is also disabled on any app with no linked repository, with a tooltip saying to set the Application Source in Developer Studio.
Honest empty and error states. An app that scanned clean says “no external provider integrations detected.” An app not yet scanned says so and offers Scan. A scan error shows the real error message on the row. A failed load shows an alert rather than an empty grid.
Data flow. The table is useListTechnicalAppsQuery over GET /v1/api-sync/technical-apps, which returns items plus totals for the filtered set. Scan, analyze, create-PR, and dismiss are mutations that return job ids or invalidate the relevant cache tags so the affected screens refresh. The detail page reads GET /v1/api-sync/inventory/:id.