API Keys

API keys are organization-scoped tokens for server-to-server access. Every key carries an explicit scope set that limits what it can do — read agents, deploy revisions, deliver webhooks, invoke MCP, and so on. You always know exactly what a leaked key could touch.

Keys are issued with the prefix fx_live_… and presented in the X-API-KEY header.

Mint a key

Settings → API Keys → Create Key.

You choose a preset or pick scopes individually:

Presets are expanded into scope sets at mint time. The preset name itself is not persisted — what's persisted is the resulting scope list.

The key is shown once. Copy it immediately; if you lose it, rotate or revoke and mint a new one.

Scope vocabulary

Scopes follow the pattern resource:action.

The live catalog is also available programmatically:

curl -X GET "https://api.fruxon.com/v1/tenants/{tenant}/apiKeys/scopes" \
  -H "X-API-KEY: $FRUXON_API_KEY"

Use the key

curl -X POST "https://api.fruxon.com/v1/tenants/{tenant}/agents/{agent}:execute" \
  -H "X-API-KEY: $FRUXON_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"input": {"topic": "the EU AI Act"}}'

To inspect the scopes on the key you're holding without revealing it elsewhere:

curl -X GET "https://api.fruxon.com/v1/tenants/{tenant}/apiKeys/current" \
  -H "X-API-KEY: $FRUXON_API_KEY"

The response includes the key's name, scopes, and last-used timestamp. Useful for SDKs and CI jobs that want to fail fast on a misprovisioned key.

Rotate a key

Rotating issues a fresh secret value while keeping the same logical key (same audit history, same downstream bindings). You can also override the name, scopes, or expiry during rotation — handy when narrowing a permissive key without re-wiring every consumer.

curl -X POST "https://api.fruxon.com/v1/tenants/{tenant}/apiKeys/{apiKey}:rotate" \
  -H "X-API-KEY: $FRUXON_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "scopes": ["agents:execute", "traces:write"],
    "expiresAt": "2026-12-31T00:00:00Z"
  }'

Both scopes and expiresAt are optional. Omit them to rotate the secret only.

Audit history

Every issuance, rotation, scope change, and revocation is recorded. View it from Settings → API Keys → select a key → Audit history, or fetch it directly:

curl -X GET "https://api.fruxon.com/v1/tenants/{tenant}/apiKeys/{apiKey}/auditEvents" \
  -H "X-API-KEY: $FRUXON_API_KEY"

Events include who triggered the change, the previous and new scope sets, and the request context.

Revision binding

When a key is used to deploy a revision, the revision records that key's ID (agent_revisions.api_key_id). This is what powers the Created by column on revisions: you can trace any deployed change back to the exact key — and from there to the human or service that issued it.

MCP keys

Each Integration Config that exposes MCP auto-mints a dedicated key scoped to mcp:invoke. You don't manage these by hand — they appear under the integration's MCP tab, with a Rotate action that issues a fresh value without disturbing the rest of your keys.

The MCP call URL and a sandbox URL are shown in the same tab once the config has been persisted.

Webhook & connector delivery

Inbound webhook and connector delivery endpoints are gated by the dedicated inbound:deliver scope. Mint a separate key with just that scope for each delivery source — leaks then can't be replayed against your control plane.

Endpoint reference

CLI

The fruxon CLI covers the read-and-revoke half of key management — fruxon keys list, revoke, delete, history, scopes. Minting and rotation are dashboard-only, by design: when an LLM agent runs the CLI, its stdout enters the agent's context window, so a CLI mint command would leak fx_live_* secrets into that pipeline. fruxon keys mint opens the browser instead, where the secret reaches a human-authenticated session without traversing the agent.

See CLI → Manage API keys for the full command surface.

Best practices

• One key per consumer. A bot, a CI pipeline, and a notebook each get their own key. Revoking one doesn't disturb the others, and the audit log stays meaningful.
• Prefer presets, narrow when needed. Start with Runner for execution, Read-only for dashboards. Drop into custom scopes only when a preset is wrong.
• Set an expiry. Even on production keys. Expired-but-rotatable beats long-lived-and-forgotten.
• Treat fx_live_* like a password. Never commit, paste, or share across environments.

Next steps

• CLI — read-and-revoke from the terminal
• Security — auth, audit, compliance posture
• Settings — where keys are managed in the UI
• API Reference — the full HTTP surface