Vendors and providers

The two-level catalog, lifecycle statuses, per-role visibility, and technical notes.

The catalog is a two-level tree: a vendor (the company — openai, amazon, deepl) owns one or more providers (a concrete API product — openai_api, amazon_translate, deepl_api). Some vendors legitimately have several providers: one account key, several models; or an MT product and an LLM product with different credentials. Codes are stable identifiers (^[a-z][a-z0-9_]{1,99}$) — store and log those, not display names.

Reading the catalog

• GET /v1/vendors — vendors without providers.
• GET /v1/vendors/{vendor_code} — one vendor plus provider summaries.
• GET /v1/providers — flat provider list; filters: category (mt/ai/custom_mt/hybrid), capability, vendor_code, status, paging.
• GET /v1/providers/{provider_code} — everything about one provider: schemas (Provider Schemas), capabilities, resolution policy, technical notes.
• GET /v1/providers/{provider_code}/technical-info — just the technical notes.
• GET /v1/catalog — the whole visible tree in one request (Full Catalog).

Every response carries catalog_version (e.g. 2026.08.24) — the version of the loaded YAML snapshot. It changes only with a deployment.

Lifecycle statuses and visibility

Vendors and providers move through active → deprecated → disabled → removed, each non-active status carrying lifecycle metadata (reason, since, optional replacement provider). What you see depends on your role:

include_removed=true from a regular role is a 403. A removed entity requested by a regular role is indistinguishable from a nonexistent one (404).

What statuses mean for stored credentials: deprecated providers accept no new credentials (409 PROVIDER_DEPRECATED_FOR_NEW_CREDENTIALS) but existing ones keep working and resolving — migrate at your pace toward lifecycle.replacement_provider_code. disabled/removed providers refuse both new credentials and resolve (409 PROVIDER_DISABLED).

The resolution policy

Each provider card carries credential_resolution: which ownership levels are allowed (user_credentials_allowed, organization_credentials_allowed, platform_credentials_allowed) and the priority order resolve walks. A provider that requires customer-owned keys simply has the platform level switched off. Details: Resolve Chain.

Technical notes

technical_info is descriptive documentation curated by catalog maintainers, not live metrics: the request unit (characters, tokens, segments), documented throughput and its source URL, supported input formats, and operational notes — auth header shapes, vendor quirks, pitfalls. last_verified_at states when a human last checked the vendor's docs. Trust it as documentation with a date, not as telemetry.