Authentication

Every API request must be authenticated. For integrations, scripts, and backend services, use an API key — a secret token prefixed with stndrds_. The standards web app itself uses short-lived session tokens instead — see User sessions.

The Authorization header

Pass your key as a Bearer token on every request:

curl https://api.standards.new/v1/records/contacts \
  -H "Authorization: Bearer stndrds_your_api_key"

Requests without a valid key are rejected with a 401. Keys are only accepted from the Authorization header — a key placed in a cookie or query parameter is ignored.

Each key belongs to a single workspace (the environment holding your objects and records). You don't need any extra header or scoping parameter — the key itself determines which workspace's data you can access. In the SDK and in multi-tenant deployments, a workspace is called a tenant.

Creating keys

Creating a key needs the create action on the api-keys system resource — held by Owner by default. Create one from the API keys area of your workspace, or from the command line:

standards keys create --name "ci-bot" --expires 2026-12-31 --yes

The plaintext secret is shown once, at creation time — copy it immediately and store it in a secrets manager (or your CI's secret store). Afterwards, the API only exposes the key's metadata (name, prefix, creation date, last use), never the secret again. If you lose it, revoke the key and create a new one.

See the CLI guide for listing and revoking keys from the terminal. Connecting Claude Code, Codex, or Cursor to your workspace? See the MCP guide — it authenticates with the same keys.

Key permissions

Keys have no permission settings of their own. Each key is an actor, and its access is exactly what its roles grant:

• By default, a new key inherits the roles of the user who created it.
• You can instead bind a key to a specific role at creation. This is the recommended setup for automations: create a dedicated role that grants only what the integration needs.

Requests beyond what the key's roles allow are refused — see what each endpoint requires.

Expiry and revocation

• Expiry — keys can carry an optional expiration date (--expires in the CLI). An expired key is rejected like an invalid one.
• Revocation — revoking a key takes effect immediately: the next request with that key gets a 401.
• Auditing — each key records when it was last used, so stale keys are easy to spot and remove.

Treat keys like passwords: never commit them to source control, never expose them in client-side code, and rotate them if you suspect a leak.

User sessions

The standards web app authenticates people, not services. Users sign in with multi-factor authentication and receive a short-lived session token. Frontends built with the SDK's app shell work the same way — each request runs as the signed-in user. For everything without a user at the keyboard — scripts, backends, server-to-server integrations — use an API key.