Mixmax Authentication

generated: '2026-08-13'
method: searched
source: https://developer.mixmax.com/reference/getting-started-with-the-api
docs: https://developer.mixmax.com/reference/getting-started-with-the-api
summary:
  types: [apiKey, oauth2, openIdConnect]
  api_key_in: [header, query]
  oauth2_flows: [authorization_code, device_code]
  note: >-
    Mixmax runs two authentication regimes side by side. The classic REST API
    (https://api.mixmax.com/v1) uses a static per-user API token with no scopes. The newer
    agent surface — the remote MCP server at https://mcp.mixmax.com/mcp — uses a full OAuth
    2.0 / OpenID Connect authorization code flow with PKCE against Mixmax's own OIDC provider.
schemes:
  - name: apiToken
    surface: REST API (https://api.mixmax.com/v1)
    type: apiKey
    in: header
    parameter: X-API-Token
    alt_in: query
    alt_parameter: apiToken
    scopes: none
    description: >-
      Mixmax authenticates every REST request with an API token. Create the token
      under Settings > Integrations (app.mixmax.com/dashboard/settings/personal/integrations);
      it is displayed only once. Send it as the X-API-Token request header, or as
      the apiToken query-string parameter.
    sources: [openapi/mixmax-openapi.yml, https://developer.mixmax.com/reference/getting-started-with-the-api]
  - name: mixmaxOAuth
    surface: MCP server (https://mcp.mixmax.com/mcp)
    type: oauth2
    flow: authorization_code
    pkce: S256
    dynamic_client_registration: true
    device_code_supported: true
    token_endpoint_auth_methods: [none]
    bearer_methods_supported: [header]
    authorization_url: https://app.mixmax.com/oidc/auth
    token_url: https://app.mixmax.com/oidc/token
    revocation_url: https://app.mixmax.com/oidc/token/revocation
    registration_url: https://app.mixmax.com/oidc/reg
    scopes: [openid, offline_access, 'meetings:read']
    ref: scopes/mixmax-scopes.yml
    description: >-
      The MCP resource server answers an unauthenticated call with 401 and an RFC 9728
      challenge — WWW-Authenticate: Bearer resource_metadata="https://mcp.mixmax.com/.well-known/oauth-protected-resource".
      Clients discover the authorization server from that document, register dynamically,
      and complete an authorization-code + PKCE flow. Access is read-only.
    sources:
      - https://mcp.mixmax.com/.well-known/oauth-protected-resource
      - https://mcp.mixmax.com/.well-known/oauth-authorization-server
      - https://success.mixmax.com/en/articles/14298142-mixmax-mcp-server
  - name: mixmaxOIDC
    surface: Mixmax identity provider
    type: openIdConnect
    openIdConnectUrl: https://app.mixmax.com/oidc/.well-known/openid-configuration
    issuer: https://app.mixmax.com/oidc
    id_token_signing_alg_values_supported: [RS256]
    subject_types_supported: [public]
    description: >-
      Mixmax operates its own OpenID Connect provider at https://app.mixmax.com/oidc, with
      full discovery, JWKS, userinfo, session end and dynamic client registration. It is the
      authorization server behind the MCP surface.
    sources: [https://app.mixmax.com/oidc/.well-known/openid-configuration]
notes:
  - Some REST endpoints (meeting summaries/transcripts) additionally require the workspace-level
    mixmaxApi feature to be enabled by an admin.
  - The REST API token is long-lived, unscoped and grants the caller everything the user can do.
    The MCP surface is the opposite — scoped, revocable, read-only. An integrator choosing
    between them should know they are not equivalent trust levels.
  - Message-integration surfaces (Enhancements, Slash Commands, Link Resolvers) are developer-hosted
    and use their own SDK context rather than either scheme above.