Enrich So Authentication

generated: '2026-08-14'
method: searched
source: https://doc.enrich.so/authentication-1951026m0
docs: https://doc.enrich.so/authentication-1951026m0
derived_from: openapi/_original/enrich-so-v3-harvested-openapi.yml
probed: '2026-08-14'
provider: Enrich
providerId: enrich-so
description: >-
  Enrich authenticates the REST API v3 with a single static, organization-scoped API key,
  accepted in either the x-api-key header (recommended) or as an Authorization Bearer
  token. There are no scopes, no per-key permissions and no OAuth on the REST API. OAuth
  2.0 exists only on the separate MCP surface at mcp.enrich.so — see
  scopes/enrich-so-scopes.yml.
summary:
  types:
  - apiKey
  - http
  oauth2: false
  scopes: false
  mtls: false
  key_rotation: supported
schemes:
- name: ApiKeyHeader
  type: apiKey
  in: header
  keyName: x-api-key
  recommended: true
  description: >-
    API key passed in the x-api-key header. Keys are created and revoked in the Enrich
    dashboard at https://dash.enrich.so/dashboard/api-keys, are scoped to the organization
    (team) behind the account, and carry member-level permissions. The key is shown once
    at creation.
  key_prefix: sk_
  prefix_note: >-
    Enrich publishes two different key formats. The authentication documentation page
    shows "sk_prod_a1b2c3d4e5f6..." while the securityScheme descriptions inside the
    OpenAPI fragments Enrich embeds in its own endpoint pages say "sk_live_ (64
    characters)". A consumer cannot tell which prefix a live key carries from the docs
    alone. Reported as an inconsistency, not resolved here.
  sources:
  - https://doc.enrich.so/authentication-1951026m0
  - openapi/_original/enrich-so-v3-harvested-openapi.yml
- name: BearerToken
  type: http
  scheme: bearer
  description: >-
    The same API key may be sent as an Authorization Bearer token
    ("Authorization: Bearer sk_..."). This is HTTP Bearer transport of a static key, not
    an OAuth access token — no token endpoint, no expiry, no refresh, and no
    WWW-Authenticate challenge is returned on 401.
  sources:
  - https://doc.enrich.so/authentication-1951026m0
  - openapi/_original/enrich-so-v3-harvested-openapi.yml
applied_to:
  operations: 51
  every_operation_requires_auth: true
  anonymous_endpoints: none
live_probe:
  url: https://dev.enrich.so/api/v3/wallets/balance
  method: GET
  credentials: none
  http_status: 401
  content_type: application/problem+json
  body: >-
    {"type":"https://dev.enrich.so/errors/unauthorized","title":"Unauthorized","status":401,
    "detail":"This endpoint requires API key authentication. Provide key via x-api-key
    header or Authorization: Bearer sk_*"}
  date: '2026-08-14'
failure_modes:
- status: 401
  cause: No key supplied, key does not start with sk_, or key is invalid.
- status: 401
  cause: Key has been disabled in the dashboard.
  remediation: Re-enable it from https://dash.enrich.so/dashboard/api-keys.
- status: 403
  cause: Account suspended.
- status: 403
  cause: The organization linked to the API key no longer exists.
- status: 429
  cause: The API key exceeded its rate limit.
key_management:
  console: https://dash.enrich.so/dashboard/api-keys
  rotation: >-
    Keys rotate from the dashboard without downtime — the old key stays active until it is
    explicitly revoked.
  per_environment_keys: recommended by Enrich (separate development and production keys)
  scoping: >-
    No per-key scoping is available. Every key can call every endpoint the organization
    has access to, including the 500-credit phone lookup and the 575-credit lead reveal.
    Separate keys per workload are the only cost-attribution mechanism.
  secret_handling: >-
    Enrich's own guidance: never commit keys, use environment variables or a secrets
    manager, rotate regularly, revoke compromised keys immediately.
mcp_surface:
  endpoint: https://mcp.enrich.so/mcp
  oauth: true
  scopes:
  - mcp:tools
  api_key_accepted: true
  note: >-
    The MCP server accepts either an OAuth token (authorization_code + PKCE, dynamic
    client registration) or the same Enrich API key via Bearer/x-api-key. Detail in
    mcp/enrich-so-mcp.yml and scopes/enrich-so-scopes.yml.
legacy_surface:
  endpoint: https://api.enrich.so
  scheme: http bearer
  bearer_format: JWT
  note: >-
    The legacy v1/v2 Enrich Labs API declares bearerAuth with bearerFormat JWT — a
    different credential model from the v3 API key. Spec at
    openapi/enrich-so-legacy-api-openapi.json.
maintainers:
- FN: Kin Lane
  email: kin@apievangelist.com