Adaptive Automation Technologies Authentication

generated: '2026-09-07'
method: searched
source: >-
  https://documentation.adaptive.live/developer-guide/adaptive-api and
  https://documentation.adaptive.live/platform/organization/mcp-servers. Derived from
  documentation rather than from a spec — Adaptive publishes no OpenAPI, so there are no
  securitySchemes to read.
description: >-
  Adaptive's programmatic surface authenticates with a Client App credential pair, not a
  single bearer token: BOTH an X-Client-ID header carrying the app's public identifier AND
  an Authorization Bearer header carrying the client secret must be present. The secret is
  shown exactly once at creation and cannot be retrieved again. A separate, per-user OAuth
  2.0 flow with RFC 7591 dynamic client registration exists for interactive MCP clients.
  End-user access to the platform itself is a third, distinct path (SSO/MFA via Okta, Azure
  AD, Google, JumpCloud, OneLogin or LDAP) and is not an API credential.
base_url: https://app.adaptive.live
base_url_note: >-
  Managed cloud. Self-hosted deployments substitute their own workspace host; the docs write
  the base as https://<your-domain>.adaptive.live and the Pulumi provider defaults
  workspaceUrl to https://app.adaptive.live.
schemes:
- id: client_app
  type: composite
  applies_to: All sixteen REST Client API operations and the headless MCP endpoint.
  required_headers:
  - name: X-Client-ID
    in: header
    value: The Client App's public identifier
    required: true
  - name: Authorization
    in: header
    value: Bearer <client-secret>
    required: true
  - name: Content-Type
    in: header
    value: application/json
    required: true
  provisioning: >-
    Organization > Client Apps > Add Client > Generate Client Secret. The secret is displayed
    once and never shown again.
  revocation: >-
    Deleting a Client App immediately stops both its API requests and any MCP connections
    that use it.
  scoped: true
  scopes_detail: scopes/adaptive-automation-technologies-scopes.yml
  scope_model: >-
    Full access (default, and the behaviour of every key created before scopes existed) or
    Restricted to a selected subset of the ten operation scopes. Scopes are fixed at
    creation — to change them you delete the key and create a new one.
  failure_modes:
  - status: 401
    body: '{"error":"bad service token: empty service token"}'
    when: No or malformed credential. Observed live on 2026-09-07.
  - status: 403
    body: operation not permitted for this key
    when: The key is restricted and lacks a scope the endpoint requires.
  docs: https://documentation.adaptive.live/developer-guide/adaptive-api
- id: mcp_oauth
  type: oauth2
  applies_to: Interactive MCP clients connecting to https://<workspace-url>/mcp
  flow: authorization_code (browser consent screen)
  dynamic_client_registration: true
  dcr_spec: RFC 7591
  endpoints_published_at_well_known: false
  endpoints_note: >-
    Issuer, Authorization, Token and Registration endpoint URLs are exposed inside the
    authenticated Organization > MCP Servers tab. Probes of
    /.well-known/oauth-authorization-server and /.well-known/oauth-protected-resource on
    every host returned 404 (or an SPA soft-404 on app.adaptive.live), so a client cannot
    discover them anonymously — see well-known/.
  token_lifetime_options: [1 day, 30 days, 90 days, 1 year, until revoked]
  scope_ceiling: >-
    The scope list offered at consent is always capped at the connecting user's own role, so
    an agent can never do more than the person who authorized it.
  optional_binding: >-
    A token may be bound to an existing Client App, intersecting its scopes with that app's
    allowed operations.
  revocation: Per-token revoke, and per-client delete, from the MCP Servers tab.
  docs: https://documentation.adaptive.live/platform/organization/mcp-servers
- id: service_token
  type: apiKey
  applies_to: The Terraform and Pulumi providers
  detail: >-
    A service account token generated in the Adaptive console. Terraform reads it from the
    `service_token` provider argument, falling back to the adaptive-cli token. Pulumi reads
    it from `adaptive:serviceToken` stack config, then the ADAPTIVE_SVC_TOKEN environment
    variable, then ~/.adaptive/token written by `adaptive login`. Where that file lists
    multiple deployments, exactly one must be marked "default": true — the provider refuses
    an ambiguous file rather than picking one at random.
  docs: https://documentation.adaptive.live/developer-guide/terraform
- id: cli_login
  type: browser
  applies_to: The Adaptive CLI
  detail: >-
    `adaptive login` opens a browser authentication prompt and writes a token to
    ~/.adaptive/token. Multiple named contexts/profiles are supported
    (`adaptive login --context-name staging --url https://staging.url.com`).
  docs: https://documentation.adaptive.live/developer-guide/adaptive-cli
platform_identity:
  note: >-
    Human sign-in to the platform is separate from API credentials and is federated.
  providers: [Okta, Azure Active Directory, Google SSO, JumpCloud, OneLogin, LDAP]
  mfa: Enforced on resources per Adaptive's access policy.
  docs: https://documentation.adaptive.live/integrations/all
x-evidence:
- url: https://app.adaptive.live/api/v3/client/users/list
  http_status: 401
  body: '{"error":"bad service token: empty service token"}'
  fetched: '2026-09-07'
- url: https://documentation.adaptive.live/developer-guide/adaptive-api
  http_status: 200
  fetched: '2026-09-07'