Emotive · Authentication Profile

Emotive Authentication

Authentication

Emotive secures its APIs with apiKey and http across 6 declared security schemes, as derived from its OpenAPI definitions.

CompanyMarketingSMSMessagingeCommerceMarketing AutomationText Message MarketingConversational CommerceWebhooksCustomer DataSegmentationAttribution
Methods: apiKey, http Schemes: 6 OAuth flows: API key in: header, cookie

Security Schemes

TokenAuth apiKey
· in: header (Authorization)
ApiKeyAuth apiKey
· in: header (X-API-Key)
AlloyKeyAuth apiKey
· in: header (X-API-Key)
InternalApiKeyAuth apiKey
· in: header (X-API-Key)
bearerAuth http
scheme: bearer
cookieAuth apiKey
· in: cookie (access_token_cookie)

Source

Authentication Profile

Raw ↑
generated: '2026-08-13'
method: searched
source: https://emotive.gitbook.io/emotive-lists/reference/authentication
docs:
- https://emotive.gitbook.io/emotive-lists/reference/authentication
- https://help.emotive.io/docs/integrations/custom-site-api
- https://help.emotive.io/docs/integrations/open-api-integration-orders
- https://help.emotive.io/docs/integrations/custom-helpdesk
derived_from:
- openapi/emotive-auth-openapi.yml
- openapi/emotive-helpdesk-openapi.yml
- openapi/emotive-open-api-openapi.yml
- openapi/emotive-subscriber-engine-openapi.yml
- openapi/emotive-sensus-webhook-openapi.yml
summary:
  types: [apiKey, http]
  api_key_in: [header, cookie]
  oauth2_declared: false
  openid_connect_declared: false
  mutual_tls: false
  note: >-
    Emotive uses three different credentials on three different surfaces and does not
    reconcile them anywhere in its documentation. The public Open API and Lists API use
    a personal access token in an `Authorization: Token <token>` header. The API gateway
    services use an `X-API-Key` header or a bearer JWT. The Auth Server exposes OAuth
    token endpoints (`POST /oauth/token`, `POST /v2/oauth/token`) plus Auth0, Google and
    Shopify login legs, but declares no `oauth2` securityScheme and publishes no scope
    list — the tokens it issues are Emotive session JWTs, not scoped API credentials.
schemes:
- name: TokenAuth
  type: apiKey
  in: header
  parameter: Authorization
  format: 'Token <access_token>'
  description: >-
    Personal access token, scheme-prefixed with the literal word "Token" and a space.
    Tokens are tied to the brand user account for which they were created. Obtained
    either by creating a List Growth API signup flow in the app (List Growth ->
    Integrations -> Add New -> List Growth API), which surfaces a key at the end of the
    wizard, or by emailing support@emotive.io for an Open API key. There is no
    self-service developer signup and no key-rotation endpoint.
  applies_to:
  - Emotive Open API (orders, opt-outs, custom events)
  - Emotive Lists API (subscriber engine)
  - Emotive Sensus Webhooks API (subscriber, profile properties)
  sources:
  - openapi/emotive-open-api-openapi.yml
  - openapi/emotive-subscriber-engine-openapi.yml
  docs: https://emotive.gitbook.io/emotive-lists/reference/authentication
  failure_response:
    status: 401
    body: '{"detail": "Authentication credentials were not provided."}'
    observed: '2026-08-13 against https://api.emotiveapp.co/ecommerce/v1/orders/'
- name: ApiKeyAuth
  type: apiKey
  in: header
  parameter: X-API-Key
  description: >-
    Brand token for the Helpdesk API. Minted by POSTing to /connections/config with an
    Emotive JWT; each brand may hold only one active token. Used for every subsequent
    Helpdesk request and for the brand's own webhook configuration.
  applies_to:
  - Emotive Helpdesk API
  - Emotive Auth Server API
  sources:
  - openapi/emotive-helpdesk-openapi.yml
  - openapi/emotive-auth-openapi.yml
  docs: https://help.emotive.io/docs/integrations/custom-helpdesk
- name: AlloyKeyAuth
  type: apiKey
  in: header
  parameter: X-API-Key
  description: Partner key variant used for the Alloy integration path on the Helpdesk service.
  sources: [openapi/emotive-helpdesk-openapi.yml]
- name: InternalApiKeyAuth
  type: apiKey
  in: header
  parameter: X-API-Key
  description: Internal service-to-service key variant declared on the Helpdesk service.
  sources: [openapi/emotive-helpdesk-openapi.yml]
- name: bearerAuth
  type: http
  scheme: bearer
  bearerFormat: JWT
  description: >-
    Emotive JWT, presented as `Authorization: bearer {emotive JWT}`. Required to bootstrap
    a Helpdesk brand token and to call the Auth Server's brand/user management operations.
  sources: [openapi/emotive-helpdesk-openapi.yml]
  docs: https://help.emotive.io/docs/integrations/custom-helpdesk
- name: cookieAuth
  type: apiKey
  in: cookie
  parameter: access_token_cookie
  description: Browser session cookie carrying the same Emotive JWT; used by the dashboard.
  sources: [openapi/emotive-helpdesk-openapi.yml]
token_endpoints:
- POST https://api-gw.emotiveapp.co/auth/oauth/token
- POST https://api-gw.emotiveapp.co/auth/v2/oauth/token
- POST https://api-gw.emotiveapp.co/auth/auth0/token
- GET  https://api-gw.emotiveapp.co/auth/google/token
- GET  https://api-gw.emotiveapp.co/auth/shopify/token
identity_providers:
- Auth0
- Google
- Shopify
gaps:
- No published OAuth scope list and no oauth2 securityScheme, despite live token endpoints.
- No self-service API key issuance for the Open API; the docs route developers to support@emotive.io.
- No documented token rotation, expiry or revocation policy.
- No /.well-known/openid-configuration or /.well-known/oauth-authorization-server on any host.