Skip to main content
KnoxCall supports two authentication paths, both fully supported, both safe to mix:
  1. OAuth 2.1 short-lived access tokens (kc_live_…, kc_test_…) — minted via POST /oauth/token, expire in 1 hour, optionally sender-constrained with DPoP (RFC 9449). This is what the SDKs use under the hood, and the recommended path for new integrations.
  2. Long-lived API keys (tk_live_…, tk_test_…, AKE…) — the original path, still works everywhere; treat it as the legacy alternative.
If you’ve used Auth0, Okta, AWS Cognito, Stripe Connect, or any modern OAuth provider, our OAuth surface will feel identical — every endpoint conforms to a published IETF RFC.

Quick start — OAuth 2.1

Your existing tk_… API key becomes the OAuth client_id + client_secret:
  • client_id = tk_abcd1234 (everything before the second underscore)
  • client_secret = the remainder
The OAuth path adds:
  • 1-hour TTL instead of long-lived
  • Scope narrowing — request a subset of your key’s permissions per call
  • DPoP sender-constraint (optional) — proof-of-possession of a keypair required per request

OAuth 2.1 endpoints

Supported grant types:
  • client_credentials — server-to-server, the simplest path
  • authorization_code + PKCE — human consent flow (with refresh tokens). Public clients may register loopback redirect URIs per RFC 8252 — http://127.0.0.1, http://[::1], and http://localhost match on any port at authorization time, so native and CLI apps can receive the callback locally.
  • urn:ietf:params:oauth:grant-type:device_code — RFC 8628 device-code flow for headless/SSH machines: POST /oauth/device_authorization returns a user code, the user approves it at /oauth/activate on any browser, and the device polls the token endpoint. This is what knoxcall login --device uses.
  • refresh_token — single-use rotation with family-detection theft protection
  • urn:ietf:params:oauth:grant-type:token-exchange — workload identity federation (GitHub Actions, GCP, AWS, Azure, Vercel)

DPoP — sender-constrained tokens (RFC 9449)

For tenants requiring the highest security tier, request DPoP-bound tokens. Send a DPoP proof JWT on the token request; the issued token is bound to your keypair via the cnf.jkt claim. Every subsequent API call must carry a fresh DPoP proof signed by the same key.

Workload identity federation (RFC 8693)

Run on GitHub Actions, GCP, AWS, Azure, or Vercel? You don’t need an API key at all. The SDK detects your platform and exchanges its OIDC token for a KnoxCall access token automatically.
Configure the trust binding once in the KnoxCall dashboard under Settings → Workload Identity. Subsequent CI runs auto-authenticate. KnoxCall ships first-party SDKs for Node.js/TypeScript, Python, Go, PHP, and Ruby (plus a Terraform provider and browser/React Elements) — see the SDKs overview for the full family. Every SDK handles token minting, caching, retries, idempotency keys, and DPoP for you.
Every SDK handles credential auto-detection, token caching, refresh, retries, and DPoP signing — your code just calls methods. Prefer raw REST? Mint a short-lived OAuth token and pass it as Authorization: Bearer <token> (a legacy tk_… key in the same header also works) and parse the JSON response.

Log in once with the CLI

On a developer machine, skip keys and env vars entirely. Every KnoxCall SDK package ships the knoxcall command (pip, npm, gem, Composer, go install — same surface, same credentials file); it runs the authorization-code + PKCE flow in your browser (or the RFC 8628 device-code flow with --device) and stores the credential in ~/.knoxcall/credentials.json:
Every KnoxCall SDK — Node.js, Python, Go, PHP, and Ruby — picks the file up automatically, so a zero-argument constructor just works:
Access tokens refresh themselves; refreshes are cross-process safe (file lock + atomic rotation of the single-use refresh token). Behind the scenes, knoxcall login uses the reserved knoxcall-cli client alias, which provisions a per-tenant system OAuth client on first login — you’ll see it on the OAuth Clients page, where it is visible but protected. See the SDKs overview for profiles (KNOXCALL_PROFILE), sandbox login, and the full credential-resolution order.

Postman / Insomnia / Bruno

KnoxCall Postman collection

Download the official collection and import it into Postman. It uses Postman’s native OAuth 2.0 support — sign in once via the Authorization tab, and every saved request inherits the token.
For other tools, point them at the OAuth 2.0 discovery URL: https://api.knoxcall.com/.well-known/oauth-authorization-server.

API Key Types

KnoxCall uses API keys to authenticate requests to the Management API. There are three types of keys, each with a distinct prefix:
Key prefixes make it easy to identify which environment a key belongs to at a glance. This follows the same live/test paradigm used by Stripe and other modern APIs.

Creating API Keys

Via the Dashboard

  1. Log in to the KnoxCall Dashboard.
  2. Navigate to Settings in the sidebar.
  3. Scroll to the API Keys section.
  4. Click Create API Key.
  5. Give your key a descriptive name (e.g., “CI/CD Pipeline”, “Backend Server”).
  6. Copy the key immediately — it will only be shown once.
API keys are displayed only once at creation time. If you lose a key, you must revoke it and create a new one. KnoxCall never stores keys in plain text after initial creation.

Via the API

You can also create API keys programmatically:
Response:
The api_key field in the response is the only time the full API key is returned. Store it securely.

Production vs. Sandbox

KnoxCall provides completely separate production and sandbox environments, following the same live/test key paradigm popularized by Stripe. Routes, secrets, environments, webhooks, vaults, crypto keys, PKI authorities, OAuth clients, and workflows are all isolated between the two modes — nothing leaks across.

Production (Live)

Management API: https://api.knoxcall.com/v1Proxy traffic: https://{slug}.knoxcall.com/{route}
  • Uses tk_live_ or AKE prefixed keys
  • Routes proxy real traffic to live upstream APIs
  • Secrets contain real credentials
  • Usage counts against your plan limits
  • Changes affect your live integrations immediately

Sandbox (Test)

Management API: https://sandbox.knoxcall.com/v1Proxy traffic: https://sandbox-{slug}.knoxcall.com/{route}
  • Uses tk_test_ prefixed keys
  • Routes, secrets, and clients are isolated from production
  • Safe for development, testing, and CI/CD
  • No impact on production traffic or billing
  • Mirrors production API behavior exactly
Using a test key against the production API (or vice versa) will return a 403 error with the type wrong_key_type. Make sure your environment configuration matches the correct base URL and key type.

Dashboard toggle

The admin dashboard has a Live / Test toggle in the bottom-left of the sidebar (look for the flask icon). Click it to switch the entire dashboard between modes — every page (Routes, Secrets, Vaults, API Keys, Webhooks, etc.) refetches and shows only the data for the active mode. An amber banner across the top of the screen confirms when you are in Test mode. While in Test mode:
  • Creating an API key automatically produces a tk_test_ test key (the standard / Enterprise Access Key options are hidden).
  • Creating any other resource (route, secret, vault, etc.) stamps it as sandbox — it is invisible from Live mode.
  • Existing live resources are not visible; you start with an empty sandbox until you populate it.
Switching back to Live mode restores the production view immediately. Your selection persists across browser sessions.

Using the SDK in sandbox mode

Both the Node and Go SDKs accept a sandbox: true option which auto-resolves the management and proxy base URLs to the sandbox hostnames:
Equivalent environment variables work everywhere (CI, Docker, etc.): set KNOXCALL_BASE_URL=https://sandbox.knoxcall.com and KNOXCALL_PROXY_BASE_URL=https://sandbox-{slug}.knoxcall.com.

Audit logs

Every audit log entry is stamped with details.sandbox: true|false so you can filter live vs test activity in the Audit Logs page or via the /v1/audit-logs endpoint. Background jobs (cron, queue workers) always emit sandbox: false.

Making Authenticated REST Requests

The SDK is the recommended path — it mints, caches, and refreshes tokens for you. Calling the REST API directly, mint a short-lived OAuth token (see Quick start) and pass it in the Authorization header as a Bearer token:

Examples

Legacy: Long-Lived API Keys

Long-lived keys (tk_live_…, tk_test_…, AKE…) remain fully supported on the Management API. Pass the key exactly where the token goes:

Legacy: Using the x-api-key Header

If your HTTP client or framework makes it difficult to set the Authorization header, you can pass a long-lived API key in the x-api-key header instead:

Authentication Errors

When authentication fails, the API returns one of these error types: Example error response:

Security Best Practices

Never expose keys in client-side code

API keys grant full access to your KnoxCall configuration. Never embed them in frontend JavaScript, mobile apps, or any code that runs in the browser.

Use environment variables

Store API keys in environment variables or a secrets manager. Never hard-code them in source files or commit them to version control.

Rotate keys regularly

Create new keys and revoke old ones on a regular cadence. If a key is compromised, revoke it immediately from the dashboard.

Use the principle of least privilege

On Enterprise plans, use scoped access keys (AKE) to limit what each key can do. For standard plans, create separate keys per service so you can revoke individually.

Environment Variable Setup

On a developer machine, prefer knoxcall login — no environment variables at all. For CI and servers, register an OAuth client (dashboard → Settings → Security → OAuth Clients) and set KNOXCALL_CLIENT_ID + KNOXCALL_CLIENT_SECRET — every SDK picks them up automatically. KNOXCALL_API_KEY remains supported as the legacy spelling for a long-lived key.
Never add .env files containing credentials to version control. Add .env to your .gitignore file.

Key Rotation Procedure

  1. Create a new API key in the dashboard or via the API.
  2. Update your application’s environment variables with the new key.
  3. Deploy the updated configuration.
  4. Verify that requests succeed with the new key.
  5. Revoke the old key in the dashboard.
Both the old and new keys will work simultaneously until you revoke the old one. This allows zero-downtime rotation.