Leanlaw Authentication

generated: '2026-08-25'
method: searched
source: https://platform.leanlaw.io/auth
docs: https://platform.leanlaw.io/auth
also_derived_from: openapi/leanlaw-api-openapi.json
summary:
  types:
  - http
  - oauth2
  primary: API key presented as an HTTP bearer token
  note: >-
    The published OpenAPI declares exactly one scheme (BearerAuth, http/bearer) applied globally to
    all 35 operations. The docs additionally document two request headers that are NOT in the spec
    (x-leanlaw-userid, x-leanlaw-partnerid), and a separate OAuth 2.1 authorization server used for
    the MCP/agent surface that is likewise absent from the spec.
schemes:
- name: BearerAuth
  type: http
  scheme: bearer
  in: header
  header: Authorization
  format: 'Authorization: Bearer {apikey}'
  applied: global
  operations_covered: 35
  sources:
  - openapi/leanlaw-api-openapi.json
  - https://platform.leanlaw.io/auth
  description: >-
    A LeanLaw API key presented as a bearer token. The key represents the ACCOUNT (the firm), not an
    individual user, and acts on behalf of the firm with the scopes selected when the key was created.
  provisioning:
    ui_path: Settings > API
    action: Generate API Key
    scope_selection: read or write permissions chosen per key at creation time
    display: shown once at creation; must be stored by the caller
    requires: firm setup / administrator access
  transport: HTTPS required
- name: OAuth2
  type: oauth2
  applied: MCP / agent surface only
  in_openapi: false
  sources:
  - https://api.leanlaw.io/.well-known/oauth-protected-resource
  - https://api.myleanlaw.co/.well-known/openid-configuration
  - https://platform.leanlaw.io/agents
  description: >-
    OAuth 2.1 authorization-code + PKCE against https://auth.myleanlaw.co/, used to authorize AI
    assistants against the MCP server. Unlike the firm-wide API key this is per USER — the connection
    carries only that person's access. Documented as private beta.
  flows:
    authorizationCode:
      authorizationUrl: https://api.myleanlaw.co/oauth/authorize
      tokenUrl: https://api.myleanlaw.co/oauth/token
      refreshUrl: https://api.myleanlaw.co/oauth/token
      revocationUrl: https://api.myleanlaw.co/oauth/revoke
  scopes: scopes/leanlaw-scopes.yml
supplemental_headers:
- name: x-leanlaw-userid
  required: false
  in_openapi: false
  description: >-
    Identifies the acting user for calls that otherwise operate at firm scope. Documented as the
    recommended approach for time-tracking use cases so matter and time-entry lists are scoped to one
    user. The userId comes from the ListUsers endpoint.
  source: https://platform.leanlaw.io/auth
- name: x-leanlaw-partnerid
  required: false
  in_openapi: false
  description: LeanLaw partners must send their partner id on all requests.
  source: https://platform.leanlaw.io/auth
gaps:
- The API key is firm-scoped rather than user-scoped, so per-user attribution depends on the caller
  voluntarily sending x-leanlaw-userid.
- Neither x-leanlaw-userid nor x-leanlaw-partnerid appears in the OpenAPI, so a generated client will
  not expose them.
- The OAuth 2.1 surface is fully discoverable at runtime but is not represented in the OpenAPI
  securitySchemes, so spec-driven tooling sees only the bearer API key.