Skip to main content
API keys let you connect external integrations and AI agents to your Traseq workspace. This page covers how to create, manage, and use them.

Quick facts

  • API keys are workspace scoped, not global credentials.
  • API key management uses JWT-authenticated workspace APIs.
  • Public Agent API calls use the API key itself.
  • Plaintext key material is returned only once at creation time.
  • Expired keys no longer authorize requests and do not count toward the active-key quota.
  • If the key creator is no longer an active workspace member, the key becomes invalid.

Key format and transport

Format:
Preferred header:
Alternative transport:

Status model

Role and scope model

Accepted roles

The current create-key flow accepts:
  • viewer
  • member
Important rule:
  • scope controls which API surfaces are available
  • role controls effective permissions inside the workspace
  • a viewer key can still be rejected on write endpoints even if write scopes were requested

Scopes

Active-key quota

The current active-key quota is tier based: An active key means:
  • revokedAt = null
  • and expiresAt is either null or still in the future
That means:
  • expired keys do not block replacement keys
  • revoked keys do not count toward the quota

Management API for API keys

These endpoints are for signed-in workspace owner or admin users. Authentication:
Base path:

List API keys

Use this to show key metadata. The plaintext secret is never returned here. Response shape:

Create an API key

Request body:
Validation rules:
  • name: required, 1-100 chars
  • description: optional, up to 500 chars
  • role: optional, member or viewer
  • scopes: optional, but if provided it must contain at least one scope
  • expiresAt: optional, but must be a future datetime
Default behavior:
  • default role is member
  • default scopes are the full public-agent set used by write-capable workflows
Create response:
Important notes:
  • apiKey is returned once, at creation time only
  • the database stores a hash, not the plaintext secret

Revoke an API key

Response shape:
Behavior:
  • revoke takes effect immediately
  • repeated revoke calls are idempotent and still return success

Using an API key with the Public Agent API

Base path:
For both developers and AI agents, the first request should be:
That lets the caller confirm:
  • which workspace the key belongs to
  • the effective role
  • granted scopes
  • subscription-tier constraints that may affect behavior
Example:

Minimal workflows

Read-only agent

Recommended for viewer keys.
  1. GET /public/v1/workspace
  2. GET /public/v1/system-strategies
  3. GET /public/v1/strategies
  4. GET /public/v1/backtests
Recommended scopes:

Write-capable agent

Recommended for member keys.
  1. GET /public/v1/workspace
  2. POST /public/v1/strategies/validate
  3. POST /public/v1/strategies
  4. POST /public/v1/strategies/:id/versions/finalize
  5. POST /public/v1/backtests
  6. GET /public/v1/backtests/:id to poll for results
Recommended scopes:

Common failures

401 Unauthorized

Typical causes:
  • missing x-api-key
  • malformed Authorization: Bearer ...
  • invalid key format
  • revoked key
  • expired key
  • key creator is no longer a workspace member
Typical messages:

403 Forbidden

Typical causes:
  • insufficient scopes
  • insufficient role, such as a viewer key calling a write endpoint
  • active-key quota reached during key creation
Quota error example:

404 Not Found

Typical management case:
  • DELETE /workspaces/:workspaceId/api-keys/:apiKeyId points to a missing key

Best practices

For developers

  • Store API keys in a secret manager — treat them like passwords.
  • Create one key per agent or environment; don’t share keys.
  • Use viewer role with read scopes for read-only workflows.
  • Use member role for agents that create strategies or run backtests.
  • Set an expiration date when possible instead of leaving keys open-ended.
  • Revoke keys you’re no longer using.

For AI agents

  • Always call GET /public/v1/workspace first to confirm your context.
  • Validate payloads with POST /public/v1/strategies/validate before writing.
  • Don’t assume backtests finish synchronously — poll with GET /public/v1/backtests/:id.
  • Use only /public/v1 endpoints for agent workflows.
  • When handling errors, check the HTTP status code first, then the response message.