generated: '2026-09-02'
method: searched
source: openapi/venafi-certificate-manager-saas-openapi.yml,
  openapi/venafi-trust-protection-foundation-websdk-openapi.yml
docs: https://docs.venafi.cloud/api/obtaining-api-key/
summary:
  types:
  - apiKey
  - http
  - oauth2
  api_key_in:
  - header
schemes:
- name: tppl-api-key
  type: apiKey
  in: header
  parameter: tppl-api-key
  api: Certificate Manager - SaaS API
  description: 'User API key, generated at account registration and readable from the console
    (avatar > Preferences > API Keys) or via `vcert getcred --email <address>`. Sent on every
    call alongside Content-Type: application/json. Keys rotate with an active/pending pair — the
    pending (previous) key stays valid until its validity period ends or it is deleted.'
  docs: https://docs.venafi.cloud/api/obtaining-api-key/
  sources:
  - openapi/venafi-certificate-manager-saas-openapi.yml
- name: service-account
  type: apiKey
  in: header
  parameter: service-account
  api: Certificate Manager - SaaS API
  description: 'Service-account credential scheme declared in the SaaS contract as an apiKey
    header named "service-account". NOTE — the provider''s own documentation states that a
    service account access token is sent in the standard `Authorization: Bearer` header, not in a
    `service-account` header; the contract and the docs disagree and this is recorded as
    published rather than reconciled. Service accounts are created via POST /v1/serviceaccounts
    and their available scopes read from GET /v1/serviceaccounts/scopes.'
  docs: https://docs.venafi.cloud/api/obtaining-api-key/
  sources:
  - openapi/venafi-certificate-manager-saas-openapi.yml
- name: AccessToken
  type: http
  scheme: bearer
  api: Trust Protection Foundation WebSDK
  description: OAuth 2.0 bearer access token issued by the customer's own Trust Protection
    Foundation authorization server. Obtained from POST /vedauth/authorize/oauth (authorization
    code), /device, /jwt, /certificate or /integrated; refreshed with POST /vedauth/authorize/token
    and revoked with DELETE /vedauth/revoke/token. Every operation declares its required scope
    (see scopes/venafi-scopes.yml).
  docs: https://docs.venafi.com/Docs/currentSDK/TopNav/Content/SDK/AuthSDK/t-SDKa-Setup-OAuth.php
  sources:
  - openapi/venafi-trust-protection-foundation-websdk-openapi.yml
- name: acme-external-account-binding
  type: other
  api: Certificate Manager - SaaS ACMEv2 server
  description: ACME clients authenticate to the Certificate Manager - SaaS ACMEv2 server with
    External Account Binding (EAB) per RFC 8555 §7.3.4. Domain-ownership challenges (HTTP-01,
    DNS-01, TLS-ALPN-01) are not used; issuance is governed by the configured application and
    request policy instead.
  docs: https://docs.venafi.cloud/vaas/configurations/acme-server-overview/
  sources:
  - https://docs.venafi.cloud/vaas/configurations/acme-server-overview/
mtls:
  supported: true
  note: POST /vedauth/authorize/certificate authenticates a client with an X.509 client
    certificate against the self-hosted authorization server.