generated: '2026-08-13'
method: searched
source: https://api-docs.partnerize.com/brand/#section/Common-API-Conventions/Access-and-Authentication
docs: https://api-docs.partnerize.com/brand/#section/Quick-Start
name: Partnerize Authentication Profile
description: >-
  The Partnerize API authenticates with HTTP Basic. The username is the User Application
  Key and the password is the User API Key, joined with a colon and Base64-encoded into a
  single Authorization header. This profile is searched from the published API reference
  rather than derived, because the OpenAPI documents Partnerize publishes declare no
  components.securitySchemes at all — the auth contract exists only in the prose of
  info.description and is therefore invisible to any tool that reads the machine-readable
  spec.
summary:
  types: [http]
  schemes: [basic]
  api_key_in: []
  oauth2_flows: []
  spec_declared: false
  docs_declared: true
schemes:
  - name: BasicAuth
    type: http
    scheme: basic
    in: header
    header: Authorization
    format: 'Basic base64(application_key + ":" + user_api_key)'
    description: >-
      HTTP Basic Authentication (RFC 7617). The application_key identifies the Network the
      request is made against; the user_api_key identifies the User on whose behalf the
      request is made. Both keys are issued per user and are retrieved from the Partnerize
      console under Settings → Account settings as "User Application Key" and "User API
      key". Access to data and operations on a given endpoint is further constrained by
      the access rights of that user, so two valid credentials may see different results
      on the same operation.
    sources:
      - https://api-docs.partnerize.com/brand/#section/Common-API-Conventions/Access-and-Authentication
      - https://api-docs.partnerize.com/partner/#section/Common-API-Conventions/Access-and-Authentication
credentials:
  - name: application_key
    role: username
    label_in_console: User Application Key
    identifies: the Partnerize Network the request is made against
    obtain: https://console.partnerize.com → Settings → Account settings
  - name: user_api_key
    role: password
    label_in_console: User API key
    identifies: the Partnerize User on whose behalf the request is made
    obtain: https://console.partnerize.com → Settings → Account settings
transport:
  https_required: true
  note: All API requests must be made over HTTPS and must carry a valid Authorization header.
authorization:
  model: per-user access rights
  description: >-
    Beyond authentication, endpoint-level access is governed by the rights of the user
    whose api_key was presented. A user without read permission on a resource receives
    404 Not Found rather than 403 Forbidden, so that the existence of the resource is not
    disclosed; a user with read but not write permission receives 403 Forbidden with an
    "unauthorized" error code naming the missing permission and resource id.
  evidence: https://api-docs.partnerize.com/brand/#section/Version-2-API-Conventions/Errors
errors:
  - status: 401
    when: wrong or invalid credentials in the Authorization header
    code: unauthorized
    message: >-
      Your API credentials can be found in Account settings. 'Username' will be your 'User
      application key' and 'Password' will be your 'User API key'
  - status: 403
    when: the authenticated user lacks the required permission on the resource
    code: unauthorized
    message: "You do not have 'read' permission on campaign with id '1'"
oauth2: false
openid_connect: false
mutual_tls: false
mobile_sdk_auth:
  - platform: ios
    note: >-
      The Partnerize iOS SDK requires no API key for the Partnerize platform; the Ascend
      platform variant does take an API key at initialisation.
    source: https://performancehorizongroup.github.io/partnerize-mobile-sdk-ios/
  - platform: android
    note: >-
      Same split — PartnerizeTracking.partnerize(context) takes no key,
      PartnerizeTracking.ascend(context, "your_ascend_api_key") does.
    source: https://performancehorizongroup.github.io/partnerize-mobile-sdk-android/
gaps:
  - >-
    None of the 104 OpenAPI documents in openapi/ declare components.securitySchemes and
    none carry a security[] requirement, on the document or on any of the 327 operations.
    A generated client or an agent reading only the spec has no way to know a credential
    is required, let alone which one. This is the single highest-value fix available to
    Partnerize on the machine-readable side, and it is a two-key change to the source
    document.
  - >-
    No /.well-known/oauth-authorization-server, /.well-known/openid-configuration or
    /.well-known/oauth-protected-resource is served on any Partnerize host — correctly so,
    since there is no OAuth surface. See well-known/partnerize-well-known.yml.
  - >-
    There is no documented key rotation policy, key scoping model, or machine-to-machine
    credential distinct from a human user's credential: an integration authenticates as a
    named Partnerize user and inherits that user's rights.