Omnisend · Authentication Profile

Omnisend Authentication

Authentication

Omnisend accepts two credentials on the same Authorization header, distinguished by prefix: "Omnisend-API-Key {key}" and "Bearer {access-token}". Both are accompanied by a REQUIRED Omnisend-Version header. This changed at version 2026-03-15 — the v3/v5 contract carried the key in a bare X-API-KEY header, which no longer applies to the /api base.

Omnisend secures its APIs with apiKey and oauth2 across 2 declared security schemes, as derived from its OpenAPI definitions. OAuth 2.0 is offered via the clientCredentials flow(s).

Email MarketingMarketing AutomationE-CommerceSMS MarketingCustomer EngagementSegmentationCampaignsFormsPopupsWeb PushAutomation WorkflowsAnalyticsMCPAgent ReadyTransactional Messaging
Methods: apiKey, oauth2 Schemes: 2 OAuth flows: clientCredentials API key in: header

Security Schemes

ApiKeyAuth apiKey
· in: header (Authorization)
Bearer oauth2
· flows: clientCredentials

Source

Authentication Profile

Raw ↑
generated: '2026-08-13'
method: searched
source: https://api-docs.omnisend.com/reference/authentication, https://api-docs.omnisend.com/reference/oauth, https://api-docs.omnisend.com/reference/getting-started,
  https://mcp.omnisend.com/.well-known/oauth-authorization-server, and openapi/omnisend-*-openapi.yml
summary:
  types:
  - apiKey
  - oauth2
  api_key_in:
  - header
  oauth2_flows:
  - clientCredentials
schemes:
- name: ApiKeyAuth
  type: apiKey
  in: header
  parameter: Authorization
  description: 'API key authentication. Use format: Omnisend-API-Key {api-key}'
  sources:
  - openapi/omnisend-analytics-api-openapi.yml
  - openapi/omnisend-automations-api-openapi.yml
  - openapi/omnisend-batches-api-openapi.yml
  - openapi/omnisend-brands-api-openapi.yml
  - openapi/omnisend-campaigns-api-openapi.yml
  - openapi/omnisend-contacts-api-openapi.yml
  - openapi/omnisend-emailcontent-api-openapi.yml
  - openapi/omnisend-emailtemplates-api-openapi.yml
  - openapi/omnisend-emailuniversallayouts-api-openapi.yml
  - openapi/omnisend-event-metadata-api-openapi.yml
  - openapi/omnisend-events-api-openapi.yml
  - openapi/omnisend-images-api-openapi.yml
  - openapi/omnisend-productcategories-api-openapi.yml
  - openapi/omnisend-products-api-openapi.yml
  - openapi/omnisend-segments-api-openapi.yml
- name: Bearer
  type: oauth2
  flows:
  - flow: clientCredentials
    tokenUrl: https://app.omnisend.com/oauth2/token
    scopes: 0
  sources:
  - openapi/omnisend-analytics-api-openapi.yml
  - openapi/omnisend-automations-api-openapi.yml
  - openapi/omnisend-batches-api-openapi.yml
  - openapi/omnisend-brands-api-openapi.yml
  - openapi/omnisend-campaigns-api-openapi.yml
  - openapi/omnisend-contacts-api-openapi.yml
  - openapi/omnisend-emailcontent-api-openapi.yml
  - openapi/omnisend-emailtemplates-api-openapi.yml
  - openapi/omnisend-emailuniversallayouts-api-openapi.yml
  - openapi/omnisend-event-metadata-api-openapi.yml
  - openapi/omnisend-events-api-openapi.yml
  - openapi/omnisend-images-api-openapi.yml
  - openapi/omnisend-productcategories-api-openapi.yml
  - openapi/omnisend-products-api-openapi.yml
  - openapi/omnisend-segments-api-openapi.yml
docs: https://api-docs.omnisend.com/reference/authentication
description: 'Omnisend accepts two credentials on the same Authorization header, distinguished by prefix: "Omnisend-API-Key
  {key}" and "Bearer {access-token}". Both are accompanied by a REQUIRED Omnisend-Version header. This changed at
  version 2026-03-15 — the v3/v5 contract carried the key in a bare X-API-KEY header, which no longer applies to
  the /api base.'
documented:
  api_key:
    header: Authorization
    format: Omnisend-API-Key {api-key}
    issued_at: https://app.omnisend.com/integrations/api-keys
    self_serve: true
    note: Shown once at creation and not retrievable afterward. Scoped to a brand.
    example: 'curl --request GET --url ''https://api.omnisend.com/api/segments'' --header ''Authorization: Omnisend-API-Key
      YOUR-API-KEY'' --header ''Omnisend-Version: 2026-03-15'''
  oauth2:
    header: Authorization
    format: Bearer {access-token}
    grant: authorization_code
    pkce: S256
    authorization_endpoint: https://app.omnisend.com/oauth2/authorize
    token_endpoint: https://app.omnisend.com/oauth2/token
    revocation_endpoint: https://app.omnisend.com/oauth2/revoke
    registration_endpoint: https://app.omnisend.com/oauth2/register
    jwks_uri: https://app.omnisend.com/.well-known/jwks.json
    client_auth_methods:
    - none
    - client_secret_post
    - client_secret_basic
    refresh: true
    token_expiry: documented as effectively never (expires_in 9223372036) unless the user revokes
    onboarding: Manual — https://forms.gle/axz6ychcELUuPrR28, credentials returned in 1-3 business days.
    required_for:
    - POST /brands/current (store connection cannot be done with an API key)
    scopes: scopes/omnisend-scopes.yml
  mcp:
    endpoint: https://mcp.omnisend.com/v2/mcp
    challenge: 401 Bearer resource_metadata="https://mcp.omnisend.com/.well-known/oauth-protected-resource"
    alternate_header: X-Api-Key
    account_roles_required:
    - Owner
    - Admin
    - Manager
    - Partner
required_headers:
- name: Omnisend-Version
  required: true
  value: '2026-03-15'
  note: 'Declared as components.parameters.APIVersionHeader with required: true in all 15 harvested contracts. A
    retired version returns 410.'
gaps:
- securitySchemes are declared in every contract but never applied — no document-level `security` block and no per-operation
  `security`, so the machine-readable contract does not state which credential any operation needs.
- The Bearer scheme is modelled in the OpenAPI as a clientCredentials flow with only two scopes, while the documented
  and live flow is authorization_code with 26 scopes. The spec understates the auth model.
- No OpenID Connect. /.well-known/openid-configuration does not serve a discovery document on any Omnisend host.
- No mutual TLS, no request signing, and no IP allowlisting documented.