TigerTrust supports three authentication mechanisms depending on who is calling:
CallerMechanism
Human user in a browserSession cookie set after login
Server-to-server / CIAPI key (ck_...)
Field agentAgent key (ak_...)
Interactive sign-inGoogle OAuth 2.0

API keys

API keys are the recommended way to call the API from scripts and integrations. They are generated per-workspace and carry a scope list. Key types
  • ck_<64 hex>client key. Use against the main REST API.
  • ak_<64 hex>agent key. Used by field agents to connect through the Collector.
API keys are returned in full only once, at creation time. Store them in a secret manager immediately — they cannot be retrieved later.

Creating an API key

Go to Integrations → API Keys → New Key, or use the API. The API surface for key management is documented at API Reference.

Using an API key

Send the full key in the X-API-Key header (preferred) or in Authorization: Bearer <key>.
curl https://api.tigertrust.example.com/api/certificates \
  -H "X-API-Key: ck_9f2a3b4c...7c4e"

Session cookies

After signing in through the login page, TigerTrust sets an httpOnly session cookie with a 7-day TTL. You can reuse this cookie for scripted requests during development.
curl -c cookies.txt -X POST https://api.tigertrust.example.com/api/auth/login \
  -H "Content-Type: application/json" \
  -d '{"email": "alice@example.com", "password": "correct-horse-battery-staple"}'

# Reuse the cookie
curl -b cookies.txt https://api.tigertrust.example.com/api/auth/user
{
  "data": {
    "message": "Login successful",
    "user": {
      "id": "usr_7f2a",
      "email": "alice@example.com",
      "firstName": "Alice",
      "currentWorkspaceId": "ws_2p9x8f4"
    }
  }
}

Google OAuth

For interactive sign-in, direct the browser to the Google sign-in flow via the sign-in page. After authenticating with Google, TigerTrust sets a session cookie — this is not an OAuth 2.0 access token flow for third parties. Server-to-server callers should use API keys instead.

Workspace selection

Session-authenticated requests default to the user’s current workspace. To act against a different workspace, add:
X-Workspace-Id: <workspace-id>
API-key requests are scoped to the workspace the key was created in; the X-Workspace-Id header is not respected for API-key calls.

Authentication errors

Authentication failures return 401 Unauthorized:
{ "error": { "code": "UNAUTHORIZED", "message": "Unauthorized" } }

See also