Skip to main content

Documentation Index

Fetch the complete documentation index at: https://runinfra.ai/docs/llms.txt

Use this file to discover all available pages before exploring further.

Two key scopes

RunInfra supports two API key types. Pick the one that matches your integration shape. A single key reaches every verified active deployment in your workspace. The model field in the request body selects the target:
curl https://api.runinfra.ai/v1/chat/completions \
  -H "Authorization: Bearer YOUR_RUNINFRA_API_KEY" \
  -d '{"model": "llama-3.3-70b", "messages": [...]}'
This matches the OpenAI SDK convention exactly, customers set base_url once and use their OpenAI code unchanged. Ideal for:
  • Dashboards with multiple model endpoints
  • Backend services that route to different models at runtime
  • Team-level integrations where one key covers all workspace pipelines

Pipeline-scoped (legacy)

A key bound to one specific pipeline. The pipeline id sits in the URL path:
curl https://api.runinfra.ai/v1/{pipelineId}/chat/completions \
  -H "Authorization: Bearer YOUR_RUNINFRA_API_KEY" \
  -d '{"messages": [...]}'
Good for:
  • Clients that should only touch one pipeline
  • Per-team keys with hard isolation
  • Existing integrations built before the workspace-scoped flow

Creating a key

1

Go to Settings → API Keys

2

Click 'Create API Key'

Pick the scope:
  • Workspace, key reaches any verified deployed model
  • Pipeline, pick a specific pipeline
3

Copy the full key immediately

The key is shown once. After you close the dialog only the hashed form is stored; we cannot recover the plaintext.
4

(Optional) Set rate limit + expiration

Rate limit defaults to your plan’s allocation. You can lower it per-key for principle-of-least-privilege. Expiration defaults to never, set a date for compliance-sensitive workflows.

Key format

Every key starts with rp_live_ followed by 64 hex chars:
rp_live_1212f66a95275a344d4042dcc9ce2c018c5251cb5be8504cd65874d776dd0d50
└──┬───┘└─────────────────────────────── 64 hex chars ──────────────────┘
 prefix
At rest the key is stored as a SHA-256 hash; the plaintext exists only in your environment. Even database compromise cannot leak usable keys directly.

Rotation

Rotate a compromised or aging key without downtime:
1

Click 'Rotate' on the key row

The UI issues a new secret and links it to the old one via rotated_from_id.
2

Update your environment with the new key

Both old and new keys work during the grace window, deploy the new secret, roll out, verify traffic.
3

Click 'Revoke' on the old key

Once traffic has drained, deactivate the prior key. All future requests with it return 401.
The rotation chain is tracked in audit_logs for SOC2 CC6.6 forensic trail.

Expiration

Keys default to never expire. For compliance or ephemeral-CI use cases, set expires_at on creation:
curl https://runinfra.ai/api/apikeys \
  -H "Authorization: Bearer <session-token>" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "ci-runner",
    "expiresAt": "2026-12-31T23:59:59Z"
  }'
A daily cron revokes expired keys (/api/cron/api-key-expiry), if it lags, the gateway still refuses the key at the first authenticated request post-expiration, so there is no window of use after expires_at.

Revocation

DELETE /api/apikeys/{id} or click Revoke in the UI. The key’s is_active flips to false and every future request returns 401 with a structured JSON body:
{
  "error": {
    "message": "API key is deactivated",
    "type": "auth_error"
  }
}

Environment variable conventions

We recommend:
# Production
RUNINFRA_API_KEY=rp_live_...
RUNINFRA_BASE_URL=https://api.runinfra.ai/v1

# Per-env keys (isolate blast radius if one env leaks)
RUNINFRA_API_KEY_DEV=rp_live_...
RUNINFRA_API_KEY_STAGING=rp_live_...
RUNINFRA_API_KEY_PROD=rp_live_...
Most SDKs pick up OPENAI_API_KEY automatically, for zero-config drop-in, map OPENAI_API_KEY=$RUNINFRA_API_KEY + OPENAI_BASE_URL=$RUNINFRA_BASE_URL.

Security posture

Hashed at rest

SHA-256 on insert; plaintext never written to disk.

Constant-time compare

Hash lookup is indexed, not string-compared, timing attacks can’t enumerate keys.

SOC2 audit log

Every failed auth, deactivation, rotation, and expiration logs to audit_logs (CC6.6).

Per-key rate limit

Upstash sliding-window per keyId, separate from network-layer Vercel DDoS protection.