Authentication

One bearer key per workspace, hashed at rest, shown to you once.

Bearer API key

Every request carries a Sentisec API key. Anthropic-shaped clients send it as x-api-key; everything else sends Authorization: Bearer. Sentisec accepts either.

curl https://api.sentisec.ch/ws/<your-workspace-id>/v1/messages \
  -H "Authorization: Bearer $SENTISEC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "Content-Type: application/json" \
  -d '{"model":"claude-sonnet-4","max_tokens":256,"messages":[{"role":"user","content":"hello"}]}'

For why the URL carries your workspace id, see your base URL.

Key format

sk_sentisec_<8 chars>_<32 chars>

• Keys are bcrypt-hashed at rest. The plaintext is shown once, at mint time — you recover a lost key by rotating it, not by looking it up.
• Keys are per workspace. A key minted in workspace A cannot authenticate against workspace B.
• Mint, name, and revoke keys in the dashboard under Settings → API keys. Each key shows its last four characters and when it was last used, so you can retire a key you no longer recognise.

Pair the CLI without copy-pasting

For interactive work — the sentisec CLI, a one-off integration test — you never have to move a key by hand.

With a browser: sentisec login

Without a browser: sentisec login --code

Use this on a server, a container, or a CI runner.

The direction matters: the dashboard mints, the CLI redeems. Generating a code needs the signed-in dashboard session, which the CLI does not have.

Pinning a request to one upstream provider

If your workspace holds several provider credentials, Sentisec picks one per request from the model id, falling back to your workspace default. To override that for a single request, name the provider:

curl https://api.sentisec.ch/ws/<your-workspace-id>/v1/chat/completions \
  -H "Authorization: Bearer $SENTISEC_API_KEY" \
  -H "X-Sentisec-Upstream-Provider: openai" \
  -H "Content-Type: application/json" \
  -d '{"model":"gpt-5.6-terra","messages":[{"role":"user","content":"hello"}]}'

Sentisec consumes the header and never forwards it upstream. A value that is not a provider name returns 400 upstream_provider_header_invalid; a real provider you have not connected returns 503 provider_unavailable. See provider errors for the full set.

Vertex AI always needs this header, or Vertex set as your workspace default. Its model ids are publisher-prefixed (google/gemini-2.5-pro), a naming shape that overlaps other providers, so Sentisec will not guess Vertex from the model id alone. See Providers.

Dashboard sign-in is separate

The operator dashboard authenticates people through your identity provider (email, or SSO with Okta, Entra, Keycloak, Zitadel, or Google Workspace). That session is not a substitute for an API key — the two surfaces are isolated by design, and the workspace ↔ organisation mapping is one to one.

Enterprise SSO →

Next

Updates / contradictions

2026-09-09 — Corrected where headless pairing codes are minted: the workspace connection setup has the code panel; the old CLI setup instructions did not themselves mint one.