Tokens

Fruxon tokens are scoped bearer credentials for programmatic access. Use them for server-to-server agent execution, MCP clients, CI jobs, webhook delivery, and other non-browser callers.

Send every Fruxon token with the standard bearer header:

Authorization: Bearer <token>

Token types

Personal access tokens and service-account tokens use the same scopes, headers, and request paths. The difference is the principal behind the credential: a personal token acts as its owning user, while a service-account token acts as a non-human workload identity. See Service Accounts when a token should belong to a workload instead of a person.

Create a personal token

Open Settings -> API Access -> Personal tokens -> Create token.

You choose a preset or pick scopes individually:

Presets are expanded into scope sets at mint time. The preset name itself is not persisted; only the resulting scope list is stored.

The token secret is shown once. Store it immediately in your secret manager. If you lose it, rotate or revoke and mint a new one.

Scope vocabulary

Scopes follow the pattern resource:action.

Discover the live vocabulary programmatically:

curl -X GET "https://api.fruxon.com/v1/tenants/{tenant}/tokens/scopes" \
  -H "Authorization: Bearer $FRUXON_TOKEN"

Use a token

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

To inspect the scopes on the token you're holding without revealing the secret:

curl -X GET "https://api.fruxon.com/v1/tenants/{tenant}/tokens/current" \
  -H "Authorization: Bearer $FRUXON_TOKEN"

The response includes the token's name, display prefix, scopes, expiry, and last-used timestamp. This is useful for SDKs and CI jobs that want to fail fast on a misprovisioned credential.

Rotate a token

Rotating mints a replacement token and revokes the old secret. By default the replacement inherits the original token's name, scopes, type, and expiry. You can also pass overrides to narrow scopes, rename the token, or set a new expiry during the same call.

curl -X POST "https://api.fruxon.com/v1/tenants/{tenant}/tokens/{token}:rotate" \
  -H "Authorization: Bearer $FRUXON_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "scopes": ["agents:execute", "traces:write"],
    "expirationDays": 90
  }'

Audit and activity

Every issuance, rotation, scope change, and revocation is recorded. View it from Settings -> API Access -> Personal tokens -> select a token -> Audit history, or fetch it directly:

curl -X GET "https://api.fruxon.com/v1/tenants/{tenant}/tokens/{token}/auditEvents" \
  -H "Authorization: Bearer $FRUXON_TOKEN"

Request activity is separate from lifecycle audit history. It is cursor-paginated because it can be high-volume:

curl -X GET "https://api.fruxon.com/v1/tenants/{tenant}/tokens/{token}/activity?pageSize=50" \
  -H "Authorization: Bearer $FRUXON_TOKEN"

Activity events include the endpoint called, status code, latency, actor, and request context.

MCP tokens

Each integration config that exposes MCP auto-mints a dedicated token 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 token inventory.

The MCP call URL and sandbox URL are shown in the same tab once the config has been persisted. See MCP for how to expose tools over MCP and point a client at the server.

Webhook and inbound delivery

Inbound webhook delivery endpoints are gated by the dedicated inbound:deliver scope. Use a separate token with only that scope for each delivery source so a leak cannot be replayed against the broader control plane.

Bearer auth is preferred. Some third-party webhook configurators can only send a static URL; those routes may carry the token in an apiKey query parameter or {apiKeyAuth} path segment. Treat URL-carried tokens as delivery-only credentials and rotate them if they appear in logs.

Endpoint reference

CLI

The fruxon CLI still exposes token management under fruxon keys for compatibility. It covers read, revoke, delete, history, and scope discovery. Minting and rotation happen in the dashboard so the full secret is shown only in a human-authenticated browser session, not printed into an LLM agent or CI log.

See CLI -> Manage tokens for the full command surface.

Best practices

• Use service accounts for workloads. A production service, webhook, scheduled job, and CI pipeline should not depend on a human user's token.
• One token per consumer. A bot, a CI pipeline, and a notebook each get their own credential. Revoking one doesn't disturb the others.
• Prefer presets, narrow when needed. Start with Runner for execution, Read-only for dashboards, then customize only when needed.
• Set an expiry. Expired-but-rotatable beats long-lived-and-forgotten.
• Treat fx_pat_* and fx_sat_* like passwords. Never commit, paste, or share them across environments.

Next steps

• Service Accounts — workload identities and fx_sat_ tokens
• CLI — read-and-revoke from the terminal
• Security — auth, audit, and credential protection
• Settings — where tokens are managed in the UI
• API Reference — the full HTTP surface