Provider catalog

The provider is the first path segment of your base URL: https://guardrails.vulnetix.com/{slug}/{orgUuid}/v1.

Slug	Provider	Surfaces
`openai`	OpenAI	`chat`, `responses`
`anthropic`	Anthropic	`messages`
`openrouter`	OpenRouter	`chat`
`groq`	Groq	`chat`
`mistral`	Mistral	`chat`
`deepseek`	DeepSeek	`chat`
`xai`	xAI	`chat`
`together`	Together AI	`chat`
`fireworks`	Fireworks AI	`chat`
`alibaba`	Alibaba Cloud	`chat`
`moonshot`	Moonshot AI	`chat`
`minimax`	MiniMax	`chat`

Every provider requires a stored key before it will proxy anything. Every provider is subject to your provider policy and model policy.

Surfaces, and why they matter

chat — POST /v1/chat/completions. What almost everything speaks.
responses — POST /v1/responses. Only openai serves it. This is what Codex CLI requires, which is why Codex can only be wired to the openai provider.
messages — POST /v1/messages. Only anthropic serves it. This is what Claude Code and Claude Desktop speak.

Asking a provider for a surface it does not serve is a 404 telling you what to use instead. See base URLs & request surfaces.

Warning

The Anthropic base URL has no /v1. The Anthropic SDK appends it itself, so the base URL stops at the organisation:

https://guardrails.vulnetix.com/anthropic/{orgUuid}

Every other provider takes the /v1 form. This asymmetry is the most common misconfiguration there is.

Model names are the provider’s own

The gateway passes the model string through verbatim — it does not rewrite, prefix, or normalise it. Use exactly the name the provider uses:

Provider	Example
`openai`	`gpt-4o-mini`
`anthropic`	`claude-sonnet-5`
`openrouter`	`openai/gpt-4o-mini` — OpenRouter namespaces by vendor
`groq`	`llama-3.3-70b-versatile`
`mistral`	`mistral-large-latest`

Get the name wrong and you get the provider’s own “unknown model” error, relayed verbatim — not one of ours. That is usually the fastest way to tell the two apart.

OpenRouter is a router, not a vendor

Warning

OpenRouter fronts models from many underlying vendors. To the firewall’s provider policy it is a single provider — so allowing openrouter grants reach to a large set of vendors you have not individually approved.

If you are using provider policy to hold a procurement or jurisdictional boundary, either deny openrouter or constrain it with model policy, which can see the individual model IDs.

The model catalog

The list of models at each provider is synced hourly. It is what GET /v1/models serves, and what the dashboard’s model pickers are populated from.

A model that is not in the catalog still works — unless the provider is in allowlist mode. This is deliberate: a model released this morning should not be an outage while the sync catches up.

The consequence is worth stating: a deny list cannot block a model that does not exist yet. If you need that guarantee, you need an allowlist.

Adding a provider

Providers are data, not code. If you need one that is not on this list — a self-hosted endpoint, Bedrock, Vertex, an OpenAI-compatible gateway of your own — get in touch. Anything that speaks one of the three surfaces and authenticates with a header can be added without a code change.

Base URLs & request surfaces
BYOK — storing a key for a provider.
Jurisdictional control — choosing vendors deliberately.