Not supported today. This page says so plainly rather than describing a path that does not exist.
What the gateway forwards to
The gateway has exactly three upstream shapes (source: apps/gateway/core/providers.py, apps/gateway/api/v1/proxy.py):
| Route | Default upstream | Auth the gateway can send |
|---|---|---|
POST /v1/chat/completions |
https://api.openai.com/v1 |
Authorization: Bearer <key> |
POST /v1/messages |
https://api.anthropic.com/v1 |
x-api-key: <key> + anthropic-version: 2023-06-01 |
POST /v1/models/{model}:generateContent |
https://generativelanguage.googleapis.com/v1beta |
x-goog-api-key: <key> |
The upstream hostname can be changed per request with X-zer0pii-Upstream-URL or per deployment with UPSTREAM_*_BASE_URL, but the auth header and the request path stay the same. There is no request signing (AWS SigV4), no Google OAuth bearer token exchange, no :invoke / :rawPredict path mapping, and no anthropic_version body field. A grep of the gateway code for bedrock or vertex returns nothing.
Why a base URL override is not enough
- Bedrock authenticates model calls with SigV4-signed requests (or a Bedrock API key) against paths like
/model/<id>/invokeand/model/<id>/converse, with its own request body shape. None of these can be produced by pointingX-zer0pii-Upstream-URLat a Bedrock endpoint. - Vertex AI uses a short-lived Google OAuth bearer token and the
:generateContent/:rawPredictpaths under a project- and region-scoped URL. The gateway can only send a staticx-goog-api-key, which Vertex does not accept.
Anthropic's own gateway compatibility guide (code.claude.com/docs/en/llm-gateway-protocol, read 2026-09-22) lists the Anthropic Messages format, Bedrock and Vertex as three distinct API formats a gateway must implement separately. zer0pii implements the first.
What works now if your models live on Bedrock or Vertex
- If the same models are also reachable for you through the provider's public API (OpenAI, Anthropic, Gemini), point the tool at zer0pii and let it forward there. The decision is a billing and data-residency one for your team; zer0pii does not change what the provider sees beyond masking.
- If your organisation runs an OpenAI-compatible front (for example a vLLM or LiteLLM deployment) in front of Bedrock or Vertex on a public hostname, the gateway can forward to it via
X-zer0pii-Upstream-URLorUPSTREAM_BASE_URLon the/v1/chat/completionsroute, using whatever bearer token that front expects inX-zer0pii-Upstream-Key. Private and internal addresses are refused by design (source:core/upstream.py, referenced fromproxy.py).
Planned follow-up
Native Bedrock and Vertex upstreams are a planned follow-up, not a scheduled one. They require new provider configurations with request signing and path mapping, and they will be documented here only once they exist in core/providers.py and are covered by the gateway test suite. If this matters to your evaluation, say so to your zer0pii contact; a named customer is what moves it onto the roadmap.