Authentication | Dike Docs

All requests to Dike's public API (/v1/*), Remote MCP Server (/mcp), and gRPC mirror require authentication via a secret Bearer API key.

Authorization: Bearer dike_live_xxxxxxxxxxxxxxxxxxxxxxxx

Key Format & Scope

Key Prefix: All live API keys begin with dike_live_ followed by 32 cryptographically random alphanumeric characters.
Comparison Security: Keys are compared server-side in constant time to prevent timing attacks and are hashed before database storage.
Unified Scope: An API key grants access to all permitted endpoints under your account's tier (/v1/search, /v1/reason, /v1/cite, /v1/document/*, /v1/graph/traverse, and /v1/jurisdictions).

Dike strictly separates Machine API Keys from Developer Portal Session Tokens:

Attribute	API Key (`/v1/*`, `/mcp`, gRPC)	Portal Session Token (`/account/*`)
Format	`dike_live_xxxxxxxx...`	JWT (`eyJhbGciOi...`)
Issuer	Created via Dashboard or `/account/keys`	Created via `POST /account/login`
Intended Consumer	Backend servers, AI agents, CLI scripts	Frontend browser, dashboard UI
Lifetime	Permanent until revoked	Short-lived (expires after session)
Interchangeability	Cannot call `/account/*` routes	Cannot call `/v1/*` routes

Do not mix credentials

Sending an API key to an /account/* route or sending a JWT session token to /v1/search will return 401 unauthorized.

You can generate, name, and revoke multiple keys in the Dike Developer Dashboard under API Credentials.

Store keys in environment variables and never commit them to source control:

# ~/.zshrc or ~/.bashrc
export DIKE_API_KEY="dike_live_xxxxxxxxxxxxxxxxxxxxxxxx"

# .env
DIKE_API_KEY=dike_live_xxxxxxxxxxxxxxxxxxxxxxxx

import os
from dotenv import load_dotenv

load_dotenv()
DIKE_API_KEY = os.getenv("DIKE_API_KEY")

import 'dotenv/config';

const apiKey = process.env.DIKE_API_KEY;

To rotate a production key without service disruption:

Create a new API key in the dashboard with a descriptive label (e.g. prod-backend-v2).
Deploy the new key to your staging and production environments.
Verify through dashboard telemetry that requests are successfully authenticated with the new key.
Revoke the old key in the dashboard. Revocations take effect immediately across all global edge nodes.