API authentication

Coming Q2 2026 with the public REST API. Email hello@atelyaos.com for early access.

The 30-second version

A public, API-key-authenticated REST API is on the roadmap for Q2 2026. The intended model is long-lived API keys scoped to a workspace, with role-based permissions matching the in-app user roles. Until then, automation surfaces are OAuth-based tool integrations and HMAC-signed outgoing webhooks.

What's coming

When the public API ships, authentication will look like this:

API keys

• Scope: per workspace. A key cannot read or write other workspaces.
• Lifetime: long-lived. Rotate from the workspace settings page.
• Permissions: tied to the role of the user who issued the key (admin, member, viewer).
• Storage: keys are shown once at creation; the database stores only a hash.

Request format (intended)

GET /api/v1/workrooms HTTP/1.1
Host: api.atelyaos.com
Authorization: Bearer atk_live_xxxxxxxxxxxxxxxxxxxxxxxx
Content-Type: application/json

Response format will be JSON. Error envelopes will include a stable error code, a human-readable message, and a request ID for support correspondence.

Plan gating

API access (can_use_api_access plan flag) is gated to Growth and above. Lower tiers will be able to use OAuth tool integrations and outgoing webhooks (see overview).

What you can do today

Until API keys ship, the supported authenticated surfaces are:

• OAuth tool integrations. Connect Notion, Google, or Slack from Settings → Integrations → Tools. The OAuth tokens are encrypted at rest and scoped per workspace.
• Outgoing webhooks (HMAC-signed). Each outgoing webhook is signed with a workspace-scoped secret. Verify the signature on receipt.
• Inbound webhook bridges. Provider-specific endpoints (Stripe billing, WhatsApp, integration callbacks) authenticate via the provider's signed-request scheme.

Internal session-cookie endpoints (the routes that power the in-app UI) are not a public contract. They can change without notice. Don't build production automation against them.

Coming soon

• API-key issuance UI in Settings → API keys.
• Stable v1 endpoints documented per resource (workrooms, deliverables, agents, credits, webhooks).
• Per-key audit trail in the activity log.
• Webhook signing rotation.

Common pitfalls

• Coding against internal session endpoints. Don't. They change with releases. Wait for the v1 public API.
• Sharing API keys across workspaces. Each key is workspace-scoped. Issue one per workspace.
• Storing keys in client-side code. API keys grant workspace-scoped access. Treat them like passwords; never ship them in browser bundles.

What's next

• API overview — what's available today.
• Webhooks — outgoing event delivery.
• Tool integrations — the OAuth-based path.