Brand API (Brandfetch) · Authentication Profile

Brand Api Authentication

Authentication

Brand API (Brandfetch) 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 authorizationCode flow(s).

BrandsLogosBrand AssetsCompany DataFirmographicsBrand ContextMerchant EnrichmentAgent Tools
Methods: http, apiKey, oauth2 Schemes: 4 OAuth flows: authorizationCode API key in: header, query

Security Schemes

bearerAuth http
scheme: bearer · in: header (Authorization)
clientId apiKey
· in: query (c)
mcpOAuth oauth2
· flows: authorizationCode
mcpToken http
scheme: bearer · in: header (Authorization)

Source

Authentication Profile

Raw ↑
generated: '2026-08-14'
method: searched
source: https://docs.brandfetch.com/.well-known/agent-skills/brandfetch/skill.md
sources:
  - openapi/brand-api-brandfetch-openapi.yml
  - https://docs.brandfetch.com/.well-known/agent-skills/brandfetch/skill.md
  - https://docs.brandfetch.com/logo-api/overview
  - https://docs.brandfetch.com/mcp/overview
  - https://developers.brandfetch.com/.well-known/oauth-authorization-server
  - https://mcp.brandfetch.io/.well-known/oauth-protected-resource
note: >-
  The OpenAPI declares only one scheme (http bearer). That is a thin spec, not the whole
  auth model: Brandfetch actually runs THREE distinct credential types across four
  surfaces, and mixing them up is the failure mode Brandfetch itself calls out in its
  published Agent Skill. This file is upgraded from the derived baseline with the docs.
summary:
  types: [http, apiKey, oauth2]
  api_key_in: [header, query]
  oauth2_flows: [authorizationCode]
  surfaces: 4
schemes:
  - name: bearerAuth
    type: http
    scheme: bearer
    in: header
    parameter: Authorization
    format: 'Authorization: Bearer <api_key>'
    applies_to: [Brand API, Brand Context API, Transaction API, Viewer API]
    sources: [openapi/brand-api-brandfetch-openapi.yml]
    declared_on_operations:
      - getBrandData
      - getBrandDataByDomain
      - getBrandDataByTicker
      - getBrandDataByIsin
      - getBrandDataByCrypto
      - getBrandContext
      - getBrandFromTransaction
      - getViewer
  - name: clientId
    type: apiKey
    in: query
    parameter: c
    format: '?c=<client_id>'
    applies_to: [Logo API, Brand Search API]
    secret: false
    sources:
      - openapi/brand-api-brandfetch-openapi.yml
      - https://docs.brandfetch.com/logo-api/overview
    note: >-
      Present in the spec as a required query parameter on searchBrands rather than as a
      securityScheme, which is why the mechanical derive missed it. The Client ID is
      embedded in the `src` of a public <img> tag and is explicitly not a secret — it
      scopes fair-use rate limiting, not authorization. Logo CDN requests additionally
      require a Referer header and a Referrer-Policy of origin, origin-when-cross-origin,
      strict-origin, strict-origin-when-cross-origin or unsafe-url.
  - name: mcpOAuth
    type: oauth2
    applies_to: [MCP server]
    issuer: https://developers.brandfetch.com
    flows:
      - flow: authorizationCode
        authorizationUrl: https://developers.brandfetch.com/oauth/authorize
        tokenUrl: https://developers.brandfetch.com/api/oauth/token
        registrationUrl: https://developers.brandfetch.com/api/oauth/register
        pkce: [S256]
        scopes: {read: Read access to Brandfetch brand data}
    sources:
      - https://developers.brandfetch.com/.well-known/oauth-authorization-server
      - https://mcp.brandfetch.io/.well-known/oauth-protected-resource
    see: scopes/brand-api-scopes.yml
  - name: mcpToken
    type: http
    scheme: bearer
    in: header
    parameter: Authorization
    prefix: 'bf1.'
    applies_to: [MCP server]
    sources: [https://docs.brandfetch.com/mcp/overview]
    note: >-
      Non-interactive fallback for MCP clients that cannot run an OAuth flow (CI,
      scripted agents). Minted in the Keys and MCP section of the developer dashboard.
credential_introspection:
  operation: getViewer
  path: GET /v2/viewer
  returns: 'ViewerApiKeyResponse | ViewerUserResponse — a `type` field says which credential was presented.'
  semantics: '200 = valid credential; 401 = missing/unknown; 403 = revoked key or expired session.'
  note: 'A genuinely useful integration-time affordance most providers do not ship.'
failure_modes:
  - 'Sending a Client ID as a Bearer token (or an API key as ?c=) returns 401 Unauthorized.'
  - 'Logo CDN requests without an acceptable Referrer-Policy can be rate limited or blocked.'
docs: https://docs.brandfetch.com/get-started