Criteo Authentication

generated: '2026-08-13'
method: searched
source: openapi/criteo-retail-media-api-openapi.yml, openapi/criteo-marketing-solutions-api-openapi.yml, openapi/criteo-commerce-grid-api-openapi.yml
docs: https://developers.criteo.com/criteo-apis/docs/api-authorization
supersedes: >-
  Rewritten 2026-08-13 against Criteo's real published OpenAPI. The prior version was derived
  from a hand-authored scaffold and carried an authorizationUrl of
  https://consent.criteo.com/authorize; the real spec and the real RFC 8414 metadata both
  give different values, recorded below.

summary:
  types: [oauth2]
  oauth2_flows: [clientCredentials, authorizationCode]
  api_key_in: []
  scope_count: 22
  token_transport: Bearer token in the Authorization header
  token_lifetime_seconds: 900
  anonymous_operations: 0
  security_coverage: >-
    All 219 operations across the three specs declare a security requirement — there are no
    unauthenticated operations. Four of them require a valid token but no specific scope
    (empty scope array): GetCurrentApplication in each of the three services, and
    ListAdvertisers in Marketing Solutions.
  token_endpoint_not_in_spec: >-
    POST https://api.criteo.com/oauth2/token is NOT declared in any of the three published
    OpenAPI documents. The one operation every client must call first is absent from the
    machine-readable contract and exists only in prose. An agent bootstrapping purely from
    the spec cannot obtain a token.

schemes:
- name: oauth
  type: oauth2
  flows:
  - flow: clientCredentials
    tokenUrl: https://api.criteo.com/oauth2/token
    declared_scopes: 0
  - flow: authorizationCode
    authorizationUrl: https://api.criteo.com/oauth2
    tokenUrl: https://api.criteo.com/oauth2/token
    declared_scopes: 0
  sources:
  - openapi/criteo-retail-media-api-openapi.yml
  - openapi/criteo-marketing-solutions-api-openapi.yml
  - openapi/criteo-commerce-grid-api-openapi.yml
  note: >-
    The flow `scopes` maps are empty in all three specs; the 22 real scope strings live on
    per-operation security requirements. See scopes/criteo-scopes.yml.

grants:
- grant: client_credentials
  audience: Server-to-server integrations acting for the app owner
  rate_limit: 250 calls/min default, 40 calls/min on reporting endpoints
  rate_limit_applies_at: application level
  consent_required: false
  note: >-
    A single shared access token per application. Criteo's own rate-limit guidance warns that
    this is the constraining choice for multi-tenant platforms: ten concurrent users share
    one 250/min budget.
- grant: authorization_code
  audience: Self-service platforms acting on behalf of a consenting advertiser
  rate_limit: 10 calls/min per consented account, scaling linearly with accounts consented
  rate_limit_applies_at: account level
  consent_required: true
  consent_url: https://consent.criteo.com/request
  revocable: true
  revocation_note: >-
    Advertisers manage and revoke app access from a consent dashboard. A revoked grant
    surfaces as HTTP 403 on subsequent calls, not 401.
- grant: refresh_token
  audience: Authorization Code applications refreshing an expired access token
  source: https://mcp.criteo.com/.well-known/oauth-authorization-server

discovery:
  rfc8414_metadata: https://mcp.criteo.com/.well-known/oauth-authorization-server
  rfc9728_metadata: https://mcp.criteo.com/.well-known/oauth-protected-resource
  issuer: https://api.criteo.com
  authorization_endpoint: https://consent.criteo.com/request
  token_endpoint: https://api.criteo.com/oauth2/token
  grant_types_supported: [authorization_code, refresh_token]
  response_types_supported: [code]
  bearer_methods_supported: [header]
  saved_to: [well-known/criteo-oauth-authorization-server.json, well-known/criteo-oauth-protected-resource.json]
  finding: >-
    Criteo publishes RFC 8414 authorization-server metadata, but ONLY on the MCP host
    (mcp.criteo.com). The same path returns 404 on api.criteo.com and developers.criteo.com,
    so a client that discovers Criteo through the REST API or the docs cannot find it. The
    metadata it publishes also omits client_credentials from grant_types_supported even
    though the REST API's primary grant IS client_credentials — the document describes the
    MCP server's grants, not the platform's.

application_model:
  docs: https://developers.criteo.com/criteo-apis/docs/create-your-app
  credentials_docs: https://developers.criteo.com/criteo-apis/docs/get-credentials
  steps:
  - Create a partner account on the developer portal
  - Create an organization
  - Create an API application, choosing a service and a per-domain authorization level
  - Retrieve client_id and client_secret
  - For Authorization Code apps, generate a consent URL and have the advertiser grant access
  note: >-
    Credentials are issued per application, not per user, and the permission set is fixed at
    app-configuration time rather than requested per token.

errors:
  '401': Missing, malformed or expired token
  '403': >-
    Valid token, but the application lacks permission on the advertiser or domain, or consent
    was never granted or has been revoked. Criteo's guidance is to relaunch the OAuth2 flow.
  caveat: >-
    On BULK endpoints a missing resource or an insufficient permission returns HTTP 200 with
    an empty response rather than 403 — documented by Criteo and important for any agent that
    treats 200 as success.
  reference: https://developers.criteo.com/criteo-apis/docs/api-error-codes