Digioh · Authentication Profile

Digioh Authentication

Authentication

Digioh secures its APIs with tenantIdentifier, http-basic, and apiKey across 4 declared security schemes, as derived from its OpenAPI definitions.

CompanyMarketingEcommercePersonalizationZero-Party DataFormsPopupsQuizzesConversion Rate OptimizationIdentity Resolution
Methods: tenantIdentifier, http-basic, apiKey Schemes: 4 OAuth flows: API key in: path, header, body

Security Schemes

ClientGUID tenantIdentifier
· in: path ({CLIENT_GUID})
OutboundBasicAuth http
scheme: basic
OutboundHeaderCredential apiKey
· in: header (Authorization (or any header name the customer configures))
DestinationPlatformCredentials apiKey

Source

Authentication Profile

digioh-authentication.yml Raw ↑
generated: '2026-08-12'
method: searched
source: >-
  https://help.digioh.com/docs/digioh-rest-api, https://help.digioh.com/knowledgebase/security-and-compliance/,
  https://github.com/digioh/digioh-ios-sdk, https://github.com/digioh/digioh-android-sdk,
  https://wordpress.org/plugins/digioh/
docs: https://help.digioh.com/docs/digioh-rest-api
derived_from_spec: false
derivation_note: >-
  0-working/derive-authentication.py was run and produced no profile - there is no OpenAPI or Swagger
  document in this repo to derive securitySchemes from, because Digioh publishes none. This file is
  authored from the provider's own documentation and from the shipped SDK signatures, and is marked
  searched accordingly.
summary:
  types: [tenantIdentifier, http-basic, apiKey]
  api_key_in: [path, header, body]
  oauth2_flows: []
  note: >-
    Digioh issues no API credential to a developer. There is no public inbound API, so there is no
    inbound auth scheme. What exists is (a) a non-secret account Client GUID that keys the widget
    runtime and the mobile SDKs, and (b) pass-through credential fields where Digioh presents the
    CUSTOMER's credentials to the CUSTOMER's own endpoint on an outbound form post.
schemes:
- name: ClientGUID
  type: tenantIdentifier
  direction: client-side
  in: path
  parameter: '{CLIENT_GUID}'
  where: >-
    Embedded in the loader URL https://www.lightboxcdn.com/vendor/{CLIENT_GUID}/lightbox_inline.js,
    passed as userGId to DigiohWeb()/Digioh() in the iOS and Android SDKs, and entered as the
    "Client GUID" / "Client ID" setting in the WordPress plugin.
  secret: false
  secret_note: >-
    This value is visible in public page source and in the CDN request path, so it identifies a
    tenant but authenticates nothing. It is retrievable in the Digioh UI under the profile menu and
    is visible to Admin users only (not subusers), per the WordPress plugin installation notes.
  sources: [https://wordpress.org/plugins/digioh/, https://github.com/digioh/digioh-ios-sdk]
- name: OutboundBasicAuth
  type: http
  scheme: basic
  direction: outbound
  where: >-
    "Basic Auth Username" and "Basic Auth Password" fields on the Advanced screen of an API Form POST
    integration. Digioh sends these to the customer's endpoint; they may be left blank.
  secret: true
  sources: [https://help.digioh.com/docs/digioh-rest-api]
- name: OutboundHeaderCredential
  type: apiKey
  in: header
  parameter: Authorization (or any header name the customer configures)
  direction: outbound
  where: >-
    Free-form HTTP header key/value pairs on the same Advanced screen, described by Digioh as the
    usual place to put "an api key or auth token". Header fields may be left blank.
  secret: true
  sources: [https://help.digioh.com/docs/digioh-rest-api]
- name: DestinationPlatformCredentials
  type: apiKey
  direction: outbound
  where: >-
    Digioh Pipelines and the legacy integrations store per-destination credentials for Klaviyo,
    Iterable, Braze, Attentive, Ometria, HubSpot, Salesforce, Yotpo, Marketo and others, entered by
    the customer when connecting the account. Each is the destination platform's own credential, not
    a Digioh-issued one.
  secret: true
  sources: [https://help.digioh.com/docs/understanding-digioh-pipelines]
account_authentication:
  sso:
    supported: true
    providers_named: [Okta, Azure AD, Google Workspace]
    protocol: not-published
    self_serve: false
    note: Enablement requires Digioh Support or a Customer Success Manager; no metadata or discovery endpoint is served.
  mfa:
    supported: true
    note: Offered on enterprise and team accounts, enabled via Digioh support.
  roles:
    supported: true
    source: https://help.digioh.com/docs/account-management-digioh-user-roles
    note: Role-based access with an Admin/subuser distinction; activity logging documented separately.
  login_url: https://account.digioh.com/
  probe_note: >-
    account.digioh.com answers 302 to /Box/List for every anonymous path and then 403, so no
    unauthenticated auth metadata is observable.
oauth2: []
gaps:
- No developer-issued API key exists, so there is no key rotation, scoping or revocation contract to document.
- No OAuth 2.0 or OpenID Connect surface; /.well-known/openid-configuration returns 404 on every host.
- SSO protocol is never named in public documentation.
evidence:
- {url: 'https://help.digioh.com/docs/digioh-rest-api', status: 200, fetched: '2026-08-12'}
- {url: 'https://help.digioh.com/knowledgebase/security-and-compliance/', status: 200, fetched: '2026-08-12'}
- {url: 'https://account.digioh.com/.well-known/openid-configuration', status: 302, fetched: '2026-08-12'}