generated: '2026-08-12'
method: searched
source: https://sourcepoint-public-api.readme.io/reference/introduction (docs) + openapi/ securitySchemes
  + live probes
docs: https://sourcepoint-public-api.readme.io/reference/introduction
summary:
  types:
  - apiKey
  - none
  api_key_in:
  - header
  note: 'Two different postures in one product: the four consent/preferences APIs declare NO security
    scheme, while the two reporting APIs require an X-API-KEY header.'
schemes:
- name: ApiKeyAuth
  type: apiKey
  in: header
  parameter: X-API-KEY
  applies_to:
  - openapi/sourcepoint-reporting-gdpr-openapi.yml
  - openapi/sourcepoint-reporting-usnat-openapi.yml
  issuance: Contact a Sourcepoint account manager - there is no self-serve key generation
  rotation: API keys generated by Sourcepoint are valid for 1 year
  quote: Use of Sourcepoint's reporting API requires an API key. ... API keys generated by Sourcepoint
    are valid for 1 year.
  source: https://sourcepoint-public-api.readme.io/reference/introduction
  observed: POST to https://portal.sourcepoint.com/api/external/v1/reports/tcfv2/dashboard-v2-pv-users/day
    with no key returned HTTP 403 "no route access" (2026-08-12), not the 401 the spec models.
- name: None (property-scoped)
  type: none
  applies_to:
  - openapi/sourcepoint-gdpr-tcf-openapi.yml
  - openapi/sourcepoint-gdpr-standard-openapi.yml
  - openapi/sourcepoint-usnat-openapi.yml
  - openapi/sourcepoint-global-enterprise-openapi.yml
  - openapi/sourcepoint-preferences-openapi.yml
  note: No securityScheme is declared on any of the 17 consent, vendor-list and preferences operations.
    Access is scoped by knowing the property id (siteId/propertyId/accountId) together with the end-user
    identifier (consentUUID / usnatUUID / globalcmpUUID / uuid) or the customer-supplied authId. These
    endpoints are served from the same CDN host the browser CMP calls, and an anonymous GET against the
    vendor-list operation returned an application-level 404 ("no active vl for siteId") rather than an
    auth challenge, confirming they answer without credentials.
  implication: Consent read and DELETE operations are addressed by identifier alone. Treat the UUIDs and
    authId as capability tokens, never log them, and expect no auth error to distinguish "wrong id" from
    "not permitted".
authenticated_consent:
  mechanism: authId
  description: A customer-supplied identifier passed to the CMP so an end-user consent profile follows
    them across devices and sessions; usable in place of the per-regulation UUID on every consent operation.
  docs: https://docs.sourcepoint.com/hc/en-us/articles/4403274791699-Authenticated-consent
oauth:
  supported: false
  note: No OAuth 2.0 or OIDC anywhere; /.well-known/openid-configuration and /.well-known/oauth-authorization-server
    miss on every host. No scopes/ artifact is emitted.
mcp:
  endpoint: https://sourcepoint-public-api.readme.io/mcp
  auth: required
  observed: HTTP 401 {"jsonrpc":"2.0","error":{"code":-32001,"message":"Authorization required"}}
  note: No WWW-Authenticate header and no /.well-known/oauth-protected-resource (404), so there is no
    advertised way for an agent to obtain the credential.