Registries

A registry is a single upstream backend that a gateway can route to. It is the one abstraction for everything downstream: there are two kinds. A registry has a name, an enabled flag, a description, and either an LLMTarget or an MCPTarget. Consumers and roles reference registries to decide where traffic goes.

​

LLM registries

An LLMTarget selects a provider and carries its options and upstream credential:

​

Supported providers

openai · openai_compatible · anthropic · azure · bedrock · google (Gemini) · vertex · groq · mistral · deepseek. Use openai_compatible (with a base_url) for any provider that speaks the OpenAI Chat Completions wire format but isn’t listed above. TrustGate normalizes the inbound format (OpenAI / Anthropic / Responses) to each provider’s wire format, so a client speaks one dialect regardless of the upstream.

​

Target auth

The credential TrustGate uses to call the provider (distinct from the consumer auth your clients use):

​

MCP registries

An MCPTarget points at an MCP server: The exchange mode supports token-exchange patterns (impersonation, delegation, obo, token_exchange) for downstream identity. See MCP.

​

Catalogs

TrustGate ships read-only catalogs to help you configure registries:

• Providers (GET /v1/providers-catalog) — supported providers, wire formats, auth types, and the options schema.
• Models (GET /v1/models-catalog) — model metadata (context window, pricing, capabilities), synced from OpenRouter.
• MCP servers (GET /v1/mcp-servers-catalog) — pre-seeded enterprise MCP servers.

​

Managing registries

CRUD lives under /v1/gateways/{gateway_id}/registries. You can test connectivity before saving (POST …/registries/test-connection) and list an MCP registry’s tools (GET …/registries/{id}/tools, which calls the live MCP server). See the Registries API.