Amika · Authentication Profile

Amika Authentication

Authentication

Amika secures its APIs with http, apiKey, and oauth2 across 4 declared security schemes, as derived from its OpenAPI definitions. OAuth 2.0 is offered via the deviceAuthorization flow(s).

CompanyAI AgentsCoding AgentsDeveloper ToolsSandboxesInfrastructureCI/CDAutomationSoftware FactoryAPI
Methods: http, apiKey, oauth2 Schemes: 4 OAuth flows: deviceAuthorization API key in: header

Security Schemes

bearerAuth http
scheme: bearer
apiKey apiKey
· in: header ()
deviceAuthorization oauth2
cookieAuth apiKey
· in: cookie ()

Source

Authentication Profile

Raw ↑
generated: '2026-07-17'
method: searched
source: https://docs.amika.dev/reference/auth.md
docs: https://docs.amika.dev/reference/auth
summary:
  types: [http, apiKey, oauth2]
  http_schemes: [bearer]
  api_key_in: [header]
  oauth2_flows: [deviceAuthorization]
  notes: >-
    The OpenAPI declares two security requirements per operation (bearerAuth and
    cookieAuth) but does not define them under components.securitySchemes. The
    profile below is reconstructed from the published authentication docs.
schemes:
- name: bearerAuth
  type: http
  scheme: bearer
  description: >-
    Bearer token in the Authorization header. The token is either a long-lived
    API key created in the web UI (app.amika.dev/settings) or a short-lived
    access token minted by the OAuth device-authorization login flow. The CLI
    resolves credentials in precedence order: AMIKA_API_KEY env var, stored API
    key file (${XDG_STATE_HOME}/amika/api-key.json), then browser login session.
  sources: [https://docs.amika.dev/reference/auth]
- name: apiKey
  type: apiKey
  in: header
  description: >-
    API keys generated in the web UI for non-interactive/CI use. Provided via
    the AMIKA_API_KEY environment variable or on-disk key file, presented as a
    bearer token to the API. Managed through the /api-keys operations.
  sources: [https://docs.amika.dev/reference/auth]
- name: deviceAuthorization
  type: oauth2
  flow: deviceAuthorization
  description: >-
    Interactive browser login for local development. The CLI requests a device
    code, the user authorizes in the browser, the CLI polls until complete, and
    a session is stored with access token, refresh token, email, and org.
    Tokens auto-refresh within 60 seconds of expiry. Identity is brokered by
    WorkOS.
  sources: [https://docs.amika.dev/reference/auth]
- name: cookieAuth
  type: apiKey
  in: cookie
  description: >-
    Session cookie accepted for browser-originated (web app) requests, offered
    as an alternative to bearerAuth on every operation.
  sources: [openapi/amika-openapi.json]