Everlit Authentication

generated: '2026-08-20'
method: searched
source: >-
  https://everlit.audio/dispatches/wordpress-plugin-audio-articles-newspack (API key statement),
  https://everlit.audio/llms-full.txt, plus live probes of https://everlit.audio/oembed,
  https://everlit.audio/embeds/<id>.json and https://studio.everlit.audio — 2026-08-20.
docs: null
summary: >-
  Everlit publishes no authentication reference page and no securitySchemes (there is no OpenAPI).
  Three distinct auth postures were established from the vendor's own copy and from live probes.
  Nothing here is inferred from a spec: every entry names the URL it came from.

schemes:
- id: none-public-embed
  type: none
  applies_to:
  - GET https://everlit.audio/oembed?url=<embed-or-hosted-url>
  - GET https://everlit.audio/embeds/{track_id}.json
  - GET https://everlit.audio/embeds/{id}
  - GET https://everlit.audio/hosted/{artl_id}
  description: >-
    The oEmbed resolver and the player bootstrap JSON answer anonymously. Verified 2026-08-20:
    HTTP 200 with no credential of any kind.
  evidence:
    url: https://everlit.audio/oembed?url=https%3A%2F%2Feverlit.audio%2Fembeds%2Fartl_9QemEuv4WkQ
    http_status: 200

- id: api-key
  type: apiKey
  applies_to:
  - Everlit REST API (undocumented, access-gated)
  - Everlit WordPress plugin configuration
  in: unknown
  name: unknown
  description: >-
    Everlit's own WordPress dispatch states that plugin "configuration requires only your Everlit
    API key". The key is issued through onboarding; Everlit publishes no key format, no header
    name, no rotation policy, no scope model and no self-serve key-issuance page.
  evidence:
    url: https://everlit.audio/dispatches/wordpress-plugin-audio-articles-newspack
    http_status: 200
  gaps:
  - Header/parameter name not published.
  - No key prefix or format documented.
  - No rotation, expiry or revocation policy published.
  - No self-serve issuance — keys come from sales/onboarding via hello@everlit.audio.

- id: session-cookie
  type: http
  scheme: session
  applies_to:
  - https://studio.everlit.audio (Everlit Studio web console)
  description: >-
    The Studio is a Rails application; the root 302s to /session/new and the HTML carries a
    csrf-token meta. Browser session auth only — not an agent-callable surface.
  evidence:
    url: https://studio.everlit.audio/
    http_status: 200
    redirects_to: https://studio.everlit.audio/session/new

- id: signed-playback-token
  type: signed-token
  applies_to:
  - GET https://everlit.audio/embeds/{track_id}/playlist?ste=<token>
  - Player analytics/share/capture callbacks
  description: >-
    The player bootstrap JSON hands the client a base64 `ste` stream token and a signed `auth_key`
    (a Rails message-verifier blob of the shape "<base64 payload>--<hmac>") that carries a user_tag,
    session_tag, article_id, channel and ad_context. These are short-lived, issued per playback,
    and are not credentials a developer can obtain or manage.
  evidence:
    url: https://everlit.audio/embeds/artl_9QemEuv4WkQ.json
    http_status: 200
    note: >-
      A request to /embeds/{id}/playlist without a live token returns HTTP 400, confirming the
      token is enforced rather than decorative.

oauth2: false
openid_connect: false
mutual_tls: false
mfa_documented: false

findings:
- The only agent-reachable Everlit surface needs no credential at all; the only credentialed
  surface (the REST API) has no public documentation, so an agent cannot self-onboard.
- No /.well-known/oauth-authorization-server, /.well-known/oauth-protected-resource or
  /.well-known/openid-configuration on any Everlit host (all 404, 2026-08-20).