Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.sequentum.com/llms.txt

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

The Sequentum Cloud API supports two authentication schemes. API keys are what most server-to-server integrations should use. OAuth bearer tokens are used by the Control Center web UI and by partners building user-facing integrations. Send your key in the Authorization header, prefixed with ApiKey: 
curl https://dashboard.sequentum.com/api/v1/agent/all \
  -H "Authorization: ApiKey $SEQUENTUM_API_KEY"

​
Generating a key

API keys are issued per user and can only be created by a workspace administrator.
  1. As an admin, open the Users page in Control Center.
  2. Find the user the key belongs to and click Manage API keys.
  3. Click New API key.
  4. Set an expiration (default: 1 year — adjust to match your security policy) and an optional description.
  5. Copy the key immediately. Sequentum stores only a hash; if the key is lost, the only path forward is to delete the entry and generate a new one.
API keys are full-access on behalf of the user they were issued to. Treat them like passwords: never commit them, never put them in client-side code, rotate when staff leave.

​
Storing keys

Use environment variables, not source files: 
export SEQUENTUM_API_KEY="..."

​
Revocation

An admin revokes a key from the same Users → Manage API keys screen. Revocation is immediate; in-flight requests using the key will continue to completion.

​
Scopes

All keys are currently full-access for the user they were issued to. Scoped keys (read-only, runs-only, billing-only) are on the roadmap.

​
OAuth bearer token

For user-context flows (the Control Center web UI, OAuth-integrated partner apps), exchange an OAuth credential for a JWT and send it as a Bearer token: 
curl https://dashboard.sequentum.com/api/v1/agent/all \
  -H "Authorization: Bearer $JWT"
The JWT carries the user’s identity and Space membership. Bearer tokens are short-lived; refresh per the standard OAuth 2.0 flow when they expire. If you’re building a server-side integration, prefer the API key path above — it’s simpler, doesn’t require a token-refresh loop, and produces clearer audit trails.