Benchmark Email · Authentication Profile

Benchmark Email Authentication

Authentication

Benchmark Email runs TWO independent API-key schemes, one per API generation, and they share nothing — not the header name, not the key format, not the permission model. There is no OAuth, no OIDC, no mTLS and no bearer token anywhere in the product; /.well-known/oauth-authorization-server, /.well-known/oauth-protected-resource and /.well-known/openid-configuration all return 404 on every host.

Benchmark Email secures its APIs with apiKey across 2 declared security schemes, as derived from its OpenAPI definitions.

Email MarketingCampaignsContactsAutomationTransactional EmailMarketingListSegmentationReportingDeliverabilitySending DomainsEmail TemplatesWebhookAgent Ready
Methods: apiKey Schemes: 2 OAuth flows: API key in: header

Security Schemes

apiKeyAuth apiKey
· in: header (X-API-Key)
apiKeyAuth apiKey
· in: header (AuthToken)

Source

Authentication Profile

Raw ↑
generated: '2026-08-13'
method: searched
source: >-
  https://developers.benchmarkemail.io/authentication (read verbatim 2026-08-13),
  openapi/benchmark-email-api-openapi.json and
  openapi/_original/benchmark-email-benchmark-email-api-openapi.yml
docs: https://developers.benchmarkemail.io/authentication
name: Benchmark Email Authentication
description: >-
  Benchmark Email runs TWO independent API-key schemes, one per API generation, and they
  share nothing — not the header name, not the key format, not the permission model. There
  is no OAuth, no OIDC, no mTLS and no bearer token anywhere in the product;
  /.well-known/oauth-authorization-server, /.well-known/oauth-protected-resource and
  /.well-known/openid-configuration all return 404 on every host.
summary:
  types:
  - apiKey
  api_key_in:
  - header
  oauth2: false
  openid_connect: false
  mutual_tls: false
  http_bearer: false
  scheme_count: 2
schemes:
- name: apiKeyAuth
  api: benchmark-email:benchmark-email-api
  api_name: Benchmark Email API v1
  type: apiKey
  in: header
  parameter: X-API-Key
  scoped: true
  description: >-
    A 50-character key of the form bme_{region}_{43 random chars}, where region is a
    two-letter code such as us, jp or eu reflecting the account's data region. Created by an
    Owner-role user at Settings > API Keys and displayed only once.
  key_format:
    prefix: bme_
    region_segment: true
    regions_documented:
    - us
    - jp
    - eu
    total_length: 50
  scopes:
  - contacts:read
  - contacts:write
  - campaigns:read
  - campaigns:write
  - reports:read
  - domains:read
  scope_semantics: write implies read
  scope_detail: scopes/benchmark-email-scopes.yml
  key_lifecycle:
  - state: Active
    behavior: Authenticates requests normally.
  - state: Inactive
    behavior: Deactivated by the owner; returns 401 Unauthorized.
  - state: Expired
    behavior: Expiration date passed; returns 401 Unauthorized.
  - state: Deleted
    behavior: Permanently removed; returns 401 Unauthorized.
  expiry: optional per key, set at creation; keys never expire if omitted
  rotation: >-
    Regenerate from the API Keys page. This invalidates the previous key and issues a new
    one. Keys can also be deactivated and reactivated without deletion, which is the
    documented way to pause an integration.
  account_standing_required:
  - open
  - pending_cancel
  account_standing_note: >-
    Suspended, past-due and terminated accounts return 403 "Account does not have API
    access" even with a valid key. Authorization therefore depends on billing state, not
    only on the key.
  quota:
    free_plan_keys: 2
    pro_plan_keys: 10
    enterprise_keys: custom
  brute_force_protection: >-
    Repeated requests with invalid keys from one IP trigger a temporary 429 block on that
    IP. See rate-limits/benchmark-email-rate-limits.yml.
  spec_gap: >-
    The OpenAPI declares this single apiKeyAuth scheme with NO scopes and NO per-operation
    security requirements, so the contract does not state which scope any operation needs.
    The scope model exists only in prose. See overlays/benchmark-email-api-overlay.yaml.
  sources:
  - https://developers.benchmarkemail.io/authentication
  - openapi/benchmark-email-api-openapi.json
- name: apiKeyAuth
  api: Benchmark Classic RESTful API v3.0
  api_name: Benchmark Classic RESTful API v3.0
  type: apiKey
  in: header
  parameter: AuthToken
  scoped: false
  description: >-
    An Admin API Token obtained from https://ui.benchmarkemail.com/Integrate#API and passed
    in the AuthToken header. All-or-nothing over the whole account — no scopes, no
    expiration and no documented rotation procedure.
  key_format:
    prefix: none published
  expiry: none published
  rotation: none published
  note: >-
    The classic use-case documentation also references a 24-hour token obtainable from an id
    and password, so a short-lived session-token path exists alongside the admin token.
  sources:
  - https://developer.benchmarkemail.com/
  - openapi/_original/benchmark-email-benchmark-email-api-openapi.yml
transport:
  https_required: true
  tls:
    www.benchmarkemail.com: TLSv1.3
    developer.benchmarkemail.com: TLSv1.3
    clientapi.benchmarkemail.com: TLSv1.2
  detail: security/benchmark-email-domain-security.yml
gaps:
- >-
  No OAuth 2.0, so there is no delegated-access path. A third-party integration cannot act
  on a customer's behalf without that customer pasting a raw account-wide API key into it.
- >-
  Credentials travel in custom headers (X-API-Key, AuthToken) rather than
  Authorization: Bearer, so standard HTTP auth tooling and proxies will not recognise them.
- >-
  The classic API's Admin API Token has no scopes, no expiry and no rotation guidance, and
  it is still the only credential for the 296-operation classic surface.