Demandbase · Authentication Profile

Demandbase Authentication

Authentication

Demandbase secures its APIs with http and oauth2 across 1 declared security scheme, as derived from its OpenAPI definitions. OAuth 2.0 is offered via the clientCredentials and authorizationCode flow(s).

Account Based MarketingAdvertisingAI AgentsB2B MarketingCompany DataContact DataData EnrichmentIntent DataMCPPersonalizationSales IntelligenceTechnographics
Methods: http, oauth2 Schemes: 1 OAuth flows: clientCredentials, authorizationCode API key in:

Security Schemes

token http
scheme: bearer

Source

Authentication Profile

Raw ↑
generated: '2026-08-13'
method: searched
source: openapi/_original/*.json (8 harvested Demandbase OpenAPI definitions)
docs:
  - https://developer.demandbase.com/docs/authenticating-with-the-apis
  - https://developer.demandbase.com/docs/migrating-from-legacy-tokens-to-api-keysets
  - https://developer.demandbase.com/reference/generate_access_token
  - https://developer.demandbase.com/docs/custom-mcp-clients
note: >-
  Demandbase runs two distinct authentication models on two distinct surfaces, and they do
  not share credentials. The REST platform APIs use an OAuth 2.0 client-credentials exchange
  against its own token endpoint and then a plain HTTP bearer token. The MCP gateway uses a
  full OAuth 2.1 authorization-code + PKCE flow with dynamic client registration against an
  Okta-backed authorization server. Both are recorded below.
summary:
  types: [http, oauth2]
  http_schemes: [bearer]
  oauth2_flows: [clientCredentials, authorizationCode]
  api_key_in: []
  mtls: false
  openid_connect: true
schemes:
  - name: token
    type: http
    scheme: bearer
    description: >-
      Bearer access token obtained from POST /auth/v1/token. Named `token` in the Admin,
      Data Export and Auth specs and `bearerAuth` in the B2B, Import, Intent, Usage and
      Custom Sources specs — the same credential either way.
    sources:
      - openapi/demandbase-admin-openapi.yml
      - openapi/demandbase-b2b-openapi.yml
      - openapi/demandbase-custom-sources-openapi.yml
      - openapi/demandbase-data-export-openapi.yml
      - openapi/demandbase-data-import-openapi.yml
      - openapi/demandbase-intent-openapi.yml
      - openapi/demandbase-usage-openapi.yml
    docs: https://developer.demandbase.com/docs/auth-api
token_exchange:
  endpoint: https://uapi.demandbase.com/auth/v1/token
  method: POST
  operation: openapi/demandbase-auth-openapi.yml#POST /auth/v1/token
  content_type: application/json
  request:
    grantType: client_credentials
    clientId: <API Key Set client ID>
    clientSecret: <API Key Set client secret>
  response:
    accessToken: bearer token for authenticated API calls
    tokenType: bearer
    expiresIn: 28800
  usage: 'Authorization: Bearer <access-token>'
  warning: Do not send the Client Secret directly in the Authorization header.
credentials:
  container: API Key Set
  scope: >-
    Platform-level, not user-level. An API Key Set is a named permission container for one
    integration; permissions are explicitly assigned to it and survive changes to any
    individual user.
  management: https://support.demandbase.com/hc/en-us/articles/38999526296603-Generate-and-Manage-API-Key-Sets
  rotation: >-
    Demandbase recommends one API Key Set per independent workload or trust boundary so
    credentials can be rotated per integration.
  legacy:
    name: Legacy API token
    shape: A single user-scoped token sent directly as the bearer token.
    risk: >-
      Because it is tied to an individual user's profile, deactivating that user breaks
      every integration using the token.
    migration: https://developer.demandbase.com/docs/migrating-from-legacy-tokens-to-api-keysets
    sunset_date: null
mcp_authentication:
  surface: https://gateway.demandbase.com/mcp/servers/db-mcp
  scheme: OAuth 2.1 authorization code + PKCE (S256)
  dynamic_client_registration: true
  registration_endpoint: https://gateway.demandbase.com/mcp/v1/register
  issuer: https://authentication.demandbase.com/oauth2/aus7fu7m8kDj90Z532p7
  authorization_endpoint: https://authentication.demandbase.com/oauth2/aus7fu7m8kDj90Z532p7/v1/authorize
  token_endpoint: https://authentication.demandbase.com/oauth2/aus7fu7m8kDj90Z532p7/v1/token
  token_endpoint_auth_methods_supported: [none]
  scopes_supported: [openid, profile, email, offline_access]
  resource: https://gateway.demandbase.com/mcp/
  protected_resource_metadata: https://gateway.demandbase.com/.well-known/oauth-protected-resource
  challenge: >-
    An unauthenticated request returns HTTP 401 with
    WWW-Authenticate: Bearer resource_metadata="…/.well-known/oauth-protected-resource",
    which is the RFC 9728 discovery bootstrap an MCP client needs.
  guidance: >-
    Demandbase explicitly instructs clients not to hardcode the authorization or token
    endpoints, and to key stored registrations and tokens on the discovered issuer.
  docs: https://developer.demandbase.com/docs/custom-mcp-clients
identity_provider:
  host: authentication.demandbase.com
  vendor: Okta
  openid_configuration: well-known/demandbase-auth-openid-configuration.json
  oauth_authorization_server: well-known/demandbase-auth-oauth-authorization-server.json
authorization:
  model: >-
    Access is governed by Permission Sets in Demandbase One, including a dedicated MCP tab
    with Full Access / Limited Access (Demandbase Data and/or Your Data) / No Access. Data
    Export access is additionally gated by the tenant's Export Collection (1-4), which
    determines which entity types and fields may be requested at all.
  docs:
    - https://support.demandbase.com/hc/en-us/articles/4408096198811-Understanding-Permission-Sets
    - https://developer.demandbase.com/docs/collections
related:
  - scopes/demandbase-scopes.yml
  - conventions/demandbase-conventions.yml
  - well-known/demandbase-well-known.yml
  - mcp/demandbase-mcp.yml