Authentication

Savitar APIs authenticate every request with a bearer token. The same primitives — API keys, OAuth 2.0, and signed JWTs — apply across every product on the platform.

API keys

Generate keys from the dashboard. Each key is scoped to an environment (test or live) and a single workspace. Pass it via the Authorization: Bearer … header.

curl https://api.savitar.dev/v1/redact \
  -H "Authorization: Bearer $SAVITAR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "text": "..." }'

OAuth 2.0

For multi-tenant apps that act on behalf of end users, register an OAuth client in the dashboard. Savitar supports the authorization code flow with PKCE. Tokens are short-lived (1 hour) and refreshable.

# Exchange an authorization code for an access token
curl -X POST https://auth.savitar.dev/oauth/token \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d "grant_type=authorization_code" \
  -d "code=$AUTH_CODE" \
  -d "code_verifier=$PKCE_VERIFIER" \
  -d "client_id=$CLIENT_ID"

JWTs (service-to-service)

Enterprise workspaces can mint short-lived JWTs signed with their tenant private key. Avoids rotating long-lived secrets in CI runners. Token lifetime is configurable from 60 seconds to 24 hours.

Authorization: Bearer <jwt>
# Claims
{
  "iss": "https://savitar.dev",
  "sub": "workspace_abc123",
  "aud": "redact-api",
  "scope": "redact:read redact:write",
  "exp": 1748213400
}

Best practices

• • Store keys in a secret manager. Never check them into source control.
• • Use a different key per service so revocation is surgical.
• • Rotate keys quarterly. Old keys remain valid for 24h after rotation.
• • Restrict keys by IP allowlist for batch and back-office workloads.