Live Direct Marketing Online Authentication

generated: '2026-09-19'
method: searched
source: https://developers.live-direct-marketing.online/authentication
docs:
  - https://developers.live-direct-marketing.online/authentication
  - https://developers.live-direct-marketing.online/api-registration
  - https://developers.live-direct-marketing.online/limits
  - https://check.live-direct-marketing.online/docs
spec:
  - openapi/live-direct-marketing-online-ldm-v3-openapi.json
  - openapi/live-direct-marketing-online-inbox-check-openapi.json
summary:
  types: [http bearer, apiKey (header), cookie session]
  api_key_in: [header]
  oauth2_flows: []
  transport: 'Authorization header, Bearer scheme, HTTPS only (HSTS on every host)'
  note: >-
    Two contracts, five declared security schemes, no OAuth 2.0 authorization server. LDM: one
    HybridAuthGuard resolves either an HttpOnly JWT cookie session (web UI) or a Bearer ldm_* tenant
    API key (agents, MCP, A2A, server-to-server) to the same handler, with per-method scope checks
    on Bearer keys. Inbox Check: Bearer icp_live_* keys with tier, scopes, provider allowlist and
    quotas, plus an X-Admin-Key header for operator routes and a session cookie for the account
    portal. The derive pass produced the scheme skeleton; this file upgrades it from the docs.
schemes:
  - name: tenant-api-key
    api: LDM v3
    type: http
    scheme: bearer
    bearerFormat: 'ldm_<64 hex chars> (contract says JWT — the docs and agent card say an opaque key)'
    description: >-
      Tenant API key for MCP / A2A / SDK / server-to-server clients. Minted in CRM Settings → API
      Keys with chosen scopes, or auto-issued by POST /api/auth/register (channel mcp|a2a|form) and by
      the MCP ldm_register tool. "One format, no separate live/test prefix."
    scopes: scopes/live-direct-marketing-online-scopes.yml (79 in the card; x-required-scope on 406 operations)
    sources: [openapi/live-direct-marketing-online-ldm-v3-openapi.json, https://developers.live-direct-marketing.online/authentication]
    declared_on_operations: 3 (as `bearer`) — the contract marks 1,265 operations with the `jwt` scheme even though the docs say every protected route accepts either credential
  - name: jwt
    api: LDM v3
    type: http
    scheme: bearer
    bearerFormat: JWT
    description: >-
      15-minute access token from POST /api/auth/login (AuthController_login), refreshed with
      POST /api/auth/refresh; carried by the web UI as an HttpOnly cookie. 401 = wrong credentials;
      403 = correct credentials but account not ACTIVE (unconfirmed email / awaiting approval / blocked).
    sources: [openapi/live-direct-marketing-online-ldm-v3-openapi.json, https://developers.live-direct-marketing.online/authentication]
    declared_on_operations: 1265
  - name: rpa-service
    api: LDM v3
    type: http
    scheme: bearer
    description: Dedicated RPA service key for the RPA service protocol (14 operations under /api/rpa/v1); "No tenant API-key or query-key authentication."
    sources: [openapi/live-direct-marketing-online-ldm-v3-openapi.json]
    declared_on_operations: 14
  - name: apiKey
    api: Inbox Check
    type: http
    scheme: bearer
    bearerFormat: 'icp_live_*'
    description: >-
      Bearer API key issued at /account (up to 3 active per user, shown once). Carries tier
      (basic/pro/enterprise), scopes (monitoring:read | monitoring:write | reports:pdf), an optional
      provider allowlist, a screenshots feature flag and daily/monthly quotas readable at GET /api/v1/me.
    sources: [openapi/live-direct-marketing-online-inbox-check-openapi.json, https://check.live-direct-marketing.online/docs]
    declared_on_operations: 38
  - name: adminKey
    api: Inbox Check
    type: apiKey
    in: header
    name_header: X-Admin-Key
    description: Operator key for /api/admin/* routes (64 operations). Not available to customers.
    sources: [openapi/live-direct-marketing-online-inbox-check-openapi.json]
    declared_on_operations: 64
  - name: cookie
    api: Inbox Check
    type: apiKey
    in: cookie
    description: >-
      Account-portal session set by POST /api/auth/login; referenced by 21 /api/account/* operations
      but NEVER DECLARED in components.securitySchemes — a contract defect. Recorded from the
      security requirements, not from a scheme object.
    sources: [openapi/live-direct-marketing-online-inbox-check-openapi.json]
    declared_on_operations: 21
credentials:
  - id: ldm-tenant-key
    header: 'Authorization: Bearer ldm_...'
    prefix: ldm_
    use: Every /api/* route for agents, MCP, A2A and integrations; scope-checked per method
    issued_by: CRM Settings → API Keys, POST /api/auth/register (agent channels), MCP ldm_register
    initial_scopes: 'SAFE_AGENT_SCOPES — read-all + safe drafts; no email:send / mailing:write until the owner expands the key after activation'
  - id: ldm-session
    header: HttpOnly cookie (JWT, 15 min) after https://app.live-direct-marketing.online/login
    prefix: null
    use: Web UI; roles OWNER / MANAGER / SUPER grant scopes
  - id: inbox-check-key
    header: 'Authorization: Bearer icp_live_...'
    prefix: icp_live_
    use: /api/v1/* and /mcp on check.live-direct-marketing.online
    issued_by: https://check.live-direct-marketing.online/account
  - id: inbox-check-admin
    header: 'X-Admin-Key: ...'
    use: operator only
anonymous_surfaces:
  - GET /api/v1/health, GET /api/public/pricing, GET /api/legal/documents[/{key}], GET /api/legal/terms, GET /api/v1/agent-guide, the .well-known cards (LDM)
  - MCP initialize + tools/list at https://api.live-direct-marketing.online/mcp (bootstrap tools only)
  - the free Inbox Placement Test web flow (no key; 3 tests per email per day)
anti_enumeration: 'Any auth failure returns the same generic 401 {"statusCode":401,"message":"Invalid credentials"} — by design.'
oauth:
  authorization_server: false
  protected_resource_metadata: 'served at /api/v1/.well-known/oauth-protected-resource with authorization_servers: [] (see well-known/)'
  note: >-
    The LDM "OAuth" tag is the platform acting as an OAuth client toward Gmail / Microsoft for the
    user's sending mailboxes; Inbox Check's /api/oauth/authorize + /api/oauth/token exist in the
    contract but are undocumented and unadvertised.
contract_gaps:
  - Both contracts declare bearerFormat JWT for keys the docs describe as opaque prefixed strings.
  - Inbox Check references an undeclared `cookie` scheme on 21 operations.
  - LDM declares `jwt` on 1,265 operations and `bearer` (undeclared name) on 3, while the docs state every protected route accepts either the cookie or the tenant key.