Provider errors (503, 401, 400, 404)

Five errors tell you something about the provider behind your request. They look similar and mean very different things, so start here.

Response	What it means
`503 provider_unavailable`	Sentisec does not carry traffic for that provider.
`401` / `402 no_upstream_credential`	The provider is available; this workspace has no key for it.
`400 upstream_provider_header_invalid`	The provider name you sent is not one Sentisec knows.
`400 bedrock_credential_missing`	The model id is an Amazon Bedrock id and no stored key can serve it.
`404 embeddings_not_supported_for_provider`	That vendor has no OpenAI-shaped embeddings endpoint.

None of these is an authentication failure on your Sentisec key — that is a plain 401 unauthorized before any provider is chosen.

503 provider_unavailable

{
  "error": "provider_unavailable",
  "provider": "azure"
}

Sentisec resolved your request to a provider it does not carry. Adding a credential will not change this — there is no upstream to send it to.

Sentisec carries Anthropic, OpenAI, Amazon Bedrock, Google Gemini, Google Vertex AI, and Kimi (Moonshot K2). Azure OpenAI is not available yet.

Fix: switch to one of the six, or tell us what you need. Full list and setup: Providers.

401 / 402 no_upstream_credential

{
  "error": "no_upstream_credential",
  "provider": "gemini"
}

Sentisec carries this provider, but your workspace has no usable key stored for it. (The status is 401 on the OpenAI-shaped routes and 402 on the Anthropic Messages route — same meaning.)

Fix: open the failed request under Requests in the dashboard. Its row shows No provider key with an Add … key action that opens Settings → Providers with that provider selected under Provider keys; add the key and retry. It takes effect on the next request; nothing restarts. The direct link is /w/<workspace-id>/settings/upstreams?provider=<provider>.

Read the provider status

The Provider keys section of Settings → Providers shows a status per provider:

Status	Meaning	What to do
`active`	A credential resolves and the provider is carried. Requests should dispatch.	Nothing.
`missing_key`	The provider is carried but no credential resolves for this workspace.	Paste a key.
`not_configured`	Nothing stored, nothing carried.	Paste a key if the provider is one of the six above.
`configured`	A credential is stored for a provider Sentisec does not carry yet.	Use an available provider.

If a credential you just saved shows missing_key, the stored value could not be read back — re-paste it. If it shows active but requests still fail with the vendor's own 401, the key was revoked or is out of quota at the vendor; rotate it there and re-paste.

400 upstream_provider_header_invalid

{
  "error": "upstream_provider_header_invalid",
  "value": "gemeni"
}

The X-Sentisec-Upstream-Provider header value is not a provider name Sentisec recognises. It is almost always a typo.

Valid values for the providers that carry traffic: anthropic, openai, bedrock, gemini, vertex, kimi.

404 embeddings_not_supported_for_provider

{
  "error": "embeddings_not_supported_for_provider",
  "provider": "anthropic"
}

POST .../v1/embeddings is served by OpenAI and Google Gemini (gemini-embedding-001). Every other provider — including Amazon Bedrock and Vertex — returns this 404, because the vendor does not expose an OpenAI-shaped embeddings endpoint on this path. No configuration changes that.

Fix: send embeddings to OpenAI or Gemini, either by using one of their embedding model ids or by pinning X-Sentisec-Upstream-Provider: openai.

400 bedrock_credential_missing

{
  "error": "bedrock_credential_missing",
  "provider": "bedrock",
  "model": "openai.gpt-oss-120b"
}

The model id is an Amazon Bedrock id, and this workspace holds no Bedrock credential and no other key that could serve the request. It is a 400 rather than the usual 401 because the actionable fact is in the body you sent: the model id names exactly which credential is missing.

Fix: add a Bedrock API key and its region under Settings → Providers, in Provider keys, or send a model id one of your existing keys serves. Setup: Amazon Bedrock.

My request went to the wrong provider

Sentisec picks a provider per request from three inputs. The header always wins; the workspace default and the model-id prefix apply when it is absent.

The X-Sentisec-Upstream-Provider header.
Your workspace's default provider, if one is configured for you. It applies only to providers that serve the wire format the request arrived on.
The model id, by prefix: claude- → Anthropic, gpt- / o1 / o3 → OpenAI, a Bedrock vendor prefix such as anthropic. / openai. / qwen. → Amazon Bedrock when the workspace holds a Bedrock credential, gemini- → Gemini, kimi- / moonshot- → Kimi.

Rules 2 and 3 are weighed in a different order on the two wire formats: an OpenAI-shaped request consults the workspace default first, an Anthropic-shaped request consults the prefix table first. The header outranks both on every route.

Three consequences worth knowing:

Vertex is never inferred from a model id. Its ids are publisher-prefixed (google/gemini-2.5-flash), a shape that overlaps other providers' naming, so Sentisec will not guess. Always send X-Sentisec-Upstream-Provider: vertex.
A Bedrock Claude id is not the same as an Anthropic one. anthropic.claude-sonnet-5 goes to Bedrock; the bare claude-sonnet-4 form goes to Anthropic direct and needs an Anthropic key.
An unfamiliar model id may land somewhere unexpected, or fail to resolve a provider at all. Pin it:
```
curl ... -H "X-Sentisec-Upstream-Provider: kimi" ...
```

The header is consumed by Sentisec and stripped before the request is forwarded, so the provider never sees it.

Everything looks connected but nothing is enforced

First check your workspace's Protection → Overview: it says whether the workspace blocks right now. New workspaces start in shadow: requests are evaluated and verdicts recorded, but actions are not blocked. A successful request or a connected status does not mean enforcement is enabled. Review the recorded verdicts, then choose Turn on enforcement on Protection → Enforce when you are ready. Existing enforcing workspaces keep their mode. See enforcement mode.

Next, check that your base URL carries your workspace id:

https://api.sentisec.ch/ws/<your-workspace-id>        # Anthropic-shaped clients
https://api.sentisec.ch/ws/<your-workspace-id>/v1     # OpenAI-shaped clients

The workspace-scoped form is what guarantees your workspace's own policy travels with every request, on every transport. Your workspace id is on the dashboard next to your API key.

Updates / contradictions

2026-09-09 — Added the missing first check for “nothing is enforced”: a new workspace deliberately starts in shadow. The workspace URL alone does not enable blocking.

2026-10-16 — The dashboard's Posture page is now Protection → Overview, and the blocking switch is on Protection → Enforce. Provider keys are under Settings → Providers, formerly Upstreams.