Skip to main content

Authentication

Autessa has three credential types for programmatic access: client API keys for executing the resources you've published, poweruser keys for managing everything in your company as yourself, and OAuth clients for letting third-party applications authenticate Autessa users.

What it's for​

Each credential answers a different question:

  • Client API keys — "let my application run these specific agents, tools, and tables." Resource-scoped and safe to hand to a production backend.
  • Poweruser keys — "let this script act as me" — create, edit, and manage every resource my account can touch, via the Poweruser API.
  • OAuth clients — "let a third-party app sign in Autessa users" via Autessa's hosted sign-in page, which redirects back to your app with a token pair.

All three are managed under API Management in the sidebar: API Keys, Poweruser Keys, and OAuth Clients.

Open API Management →

Key concepts​

Client API keys​

Client keys authenticate the Client API — executing agents, tools, and AutessaDB. Requests pass the raw key in the Authorization header (no Bearer prefix) and select the resource with a resourceId query parameter; WebSocket endpoints take the key as an ?authorization= query parameter instead.

curl "https://api.autessa.com/clients/agents/execute?resourceId=V1StGXR8Z5" \
  -H "Authorization: $API_KEY"

When creating a key you set its name, per-minute and per-day rate limits, an optional allowed-origins list, and — most importantly — its resource access: all resources, or a hand-picked set of agents, tools, and AutessaDB tables (tables with per-table READ/WRITE/DELETE granularity). The key value is shown once at creation; Reset token rotates it later. See API Keys.

Poweruser keys​

A poweruser key is a personal, full-management credential with the shape pwrusr:{id}:{secret}, passed in the Authorization header. Every call acts as your user — same resources, same permissions — against the Poweruser API, which covers management of agents, tools, tables, envelopes, connectors, and more.

curl https://api.autessa.com/poweruser/... \
  -H "Authorization: $POWERUSER_KEY"

Each user has at most one active permanent key, plus on-demand temporary keys that expire after 15 minutes. Keys can be rotated (invalidates the old one immediately) or revoked. Because poweruser access is broad, delegated uses of it are endpoint-scoped — for example, a hosted custom app must declare exactly which poweruser endpoints it may call on the owner's behalf. See Poweruser Keys.

OAuth clients​

OAuth clients make Autessa an OAuth 2.0 provider for your own applications: register a client, send users to Autessa's hosted /oauth/login page with your client_id and redirect_uri, and on success Autessa redirects back to your app with access_token, refresh_token, expires_in, and token_type in the URL fragment — there is no authorization-code exchange step. Refresh and revoke endpoints round out the token lifecycle. You configure a client name, a type — Public (SPA / browser extension, no secret) or Confidential (server-side, secret shown once and required on refresh) — and redirect URIs. New clients may require Autessa admin approval before use. See OAuth Clients.

Never expose a credential in client-side code. Client keys support an allowed-origins list, but the key itself still belongs on a server; poweruser keys and OAuth client secrets are strictly server-side.

How to choose​

  1. Embedding a published agent, tool, or table in your product → create a client API key scoped to exactly those resources.
  2. Automating your workspace — provisioning resources, CI, migrations, back-office scripts → generate a poweruser key (or a 15-minute temporary key for one-off jobs).
  3. Building a third-party app that signs in Autessa users → register an OAuth client.
  4. Reacting to inbound events from other systems → you may not need a credential at all; see Webhook Handlers.