The API Catalog maps your organization’s internal API surface: where gRPC and Thrift services are defined, and where they are called from, across all scanned repositories. Each scan uploads the gRPC and Thrift service definitions, methods, and call sites it found in that repository; the platform links them across all your repositories by fully qualified service name, so a call site in one repository resolves to the service defined in another.
The catalog has two sections:
- gRPC — services discovered from
.protodefinitions and their call sites. - Thrift — services discovered from
.thriftdefinitions and their call sites.
Definitions come from .proto and .thrift files; server implementations and call sites are detected in Go, Python,
Java, C#, JavaScript, and TypeScript.
Service Detail
Section titled “Service Detail”Click a service to see:
- RPC Methods — the service’s methods with the file and line where each is defined, filterable by method name and repository.
- Call Sites — every location where the service is called, with the method name, repository, branch, commit, file, and line, filterable by method and repository. Call sites are recorded from primary-branch scans only; service definitions are updated by any scan.
- Extends (Thrift only) — the parent service, when the Thrift service inherits from another, linked to its catalog entry.
- Datamap — a per-service view of the sensitive data elements flowing through the service’s methods.
Why It Matters
Section titled “Why It Matters”Internal APIs are a common blind spot in data mapping: a service may receive sensitive data from a caller in a different repository. Because the platform correlates service definitions and call sites across repositories, the API Catalog shows these cross-repository flows with code-level evidence.
An equivalent catalog for the repository you are working in is available to AI coding agents on your machine through the scanner’s MCP server, served from the local scan state store rather than from the platform.