// Docs · Authentication

One header. One prefix.

SLASHED uses bearer-token authentication via the standard Authorization header. Keys are prefixed sl-. There is no second factor, no signed request, no HMAC. If your OpenAI code already works, your SLASHED code already works.

01The header

Every authenticated request carries an Authorization header in this exact shape:

Authorization: Bearer sl-...

The OpenAI SDK sets this for you when you pass api_key="sl-...". The Anthropic SDK does not set this header in this shape — see /docs/migrate if you are coming from the Anthropic native SDK.

02Key structure

A SLASHED key is a single opaque string. The sl- prefix is the only stable identifier portion; the rest is secret material. The prefix is documented as sl- across the entire fleet — no separate live/test prefixes today.

sl-a7f3c2b4_secretsecretsecretsecretsecretsecret

sl-Public prefix. Identifies the gateway. Always present. a7f3c2b4Short identifier. Lets dashboard surface key-name and last-used. _secret...Secret material. Shown once, at creation. Not recoverable.

// Show-once semantics The full secret is displayed in the dashboard one time, at creation. If you lose it, rotate — you cannot read it back. The dashboard records the prefix and a hash for display and audit; the secret half is never re-emitted.

03Per-key scopes

Each key can be scoped at creation. Documented scope dimensions:

Scope	Effect	Default
`model allowlist`	If set, the key may only be used with the listed model IDs. Requests for other IDs return `403 model_not_allowed`.	All 11 models
`monthly cap (USD)`	Hard cap on accumulated spend for the calendar month. Past the cap, requests return `402 monthly_cap_exceeded`.	No cap
`name / label`	Free-text. Surfaces in the dashboard ledger only. Not sent upstream.	empty

Per-key rate limits, per-key IP allowlists, and per-key web-origin restrictions are not documented as available today. If you need any of those, route through your own proxy.

04Rotation

Rotation is a two-step ceremony:

Create a second key with the same scopes from Dashboard → Keys → New. You now have two valid keys.
Swap your SLASHED_API_KEY env var (or equivalent) to the new key, redeploy, verify traffic on the new key in the dashboard ledger.
Revoke the old key from Dashboard → Keys → ⋯ → Revoke. Revocation is immediate — in-flight requests on the revoked key fail with 401 invalid_api_key.

Documented rotation cadence: at your discretion. There is no forced expiry today.

05Compromised key

If you suspect a key is exposed:

Revoke immediately from the dashboard. The revoke is propagated within seconds.
Inspect the ledger for the period since you believe the key was exposed. Each completed request is timestamped and attributed.
Create a replacement with stricter scopes (model allowlist + monthly cap) and update your deployment.

06What we don't do (today)

No OAuth, no SSO, no SAML on the API layer. Dashboard sign-in is separate from key auth.
No request signing. The Bearer header is the entire authentication surface.
No mutual TLS / client cert auth.
No JWT / short-lived token issuance. Keys are long-lived until you revoke.

// Documented — not guaranteed Authentication behaviour described on this page is what SLASHED documents today. Backend semantics around revoke propagation latency, cap accounting windows, and ledger commit ordering are best-effort. If your use case depends on stricter guarantees, raise it with support before integration.

← Previous

Quickstart

Models