Provider Catalog

The Provider Catalog is the directory of external providers API Sync supports. It is where you check whether a provider you depend on is covered, how deeply, and how API Sync keeps up with it. Providers are grouped by category, and each card opens a detail drawer.

What it does#

Cards grouped by category. Every provider is a card showing its logo, name, category, coverage source, and coverage depth. Cards are grouped under category headers (AI and LLM, Authentication and Identity, and so on), and each header carries a count. A provider you actually use is marked with a check and a “you use this provider” note.

Search and filter. The header has a category dropdown and a provider search box. The two combine: pick a category, type a name, and the grid narrows to matching providers. Clearing the search is one click.

Three coverage sources. The core idea of the catalog is who maintains a provider:

• Partner-maintained means the provider has onboarded and publishes its own change and knowledge packs. This is the authoritative source.
• Platform-maintained means the provider has not onboarded yet, so API Sync keeps it current by pulling public specs, SDK releases, and changelogs.
• Detected, unsupported means the provider showed up in your code but is not yet in the registry.

A detail drawer. Clicking a card opens a drawer with the provider’s logo, its coverage source, and whether you use it. Stat tiles show coverage depth, knowledge base status, latest API version, open changes, consumer count, and whether you use it. A short note explains how that specific provider is kept in sync, based on its source. When a website is known, a “Visit website” button links out.

How it behaves#

A seeded, editable registry. The catalog ships with a curated default set spanning sixteen categories of well-known providers, each with the website that drives its logo. The seed loads once on a fresh database, and edits or deletions persist after that, so the catalog reflects your registry rather than resetting.

Grouping and sorting are deterministic. Categories are sorted alphabetically, and providers are sorted by name within each category, so the same catalog always reads the same way.

Honest empty states, two kinds. If the catalog itself is empty, the screen says so. If your search and filter match nothing, it says that instead, so an empty result never looks like a broken screen.

Read-only for consumers. From the consumer side, the catalog is for looking things up. Adding change records and versions to a provider happens on the Partner Provider side.

Data flow. The catalog is useListProvidersQuery over GET /v1/api-sync/providers. Category grouping, filtering, and search all run in the browser over that one response, so switching filters is instant.