Ladder · Authentication Profile

Ladder Authentication

Authentication

Ladder's partner API is a client-side embedded integration, so its authentication model is a partner-minted user token rather than a provider-issued API key used from a browser. The public integration example shows the partner's own backend producing a user auth token which is passed to the LadderAPI constructor loaded in the page; the token identifies the end user on whose behalf the quoting/application flow is mounted. Ladder does not publish an OpenAPI document, an OAuth authorization server, or an OIDC discovery document (both /.well-known/oauth-authorization-server and /.well-known/openid-configuration return 404), and full reference credentials are issued only after a partner access request is approved. No scope surface is published, so no scopes/ artifact is asserted.

Ladder secures its APIs with bearer-token across 1 declared security scheme, as derived from its OpenAPI definitions.

CompanyInsuranceInsurtechLife InsuranceEmbedded FinanceEmbedded InsuranceFinancial ServicesFintechQuoting
Methods: bearer-token Schemes: 1 OAuth flows: API key in:

Security Schemes

userToken bearer-token

Source

Authentication Profile

ladder-authentication.yml Raw ↑
generated: '2026-07-19'
method: searched
source: https://www.ladderlife.com/api
docs: https://www.ladderlife.com/api
description: >-
  Ladder's partner API is a client-side embedded integration, so its
  authentication model is a partner-minted user token rather than a
  provider-issued API key used from a browser. The public integration example
  shows the partner's own backend producing a user auth token which is passed to
  the LadderAPI constructor loaded in the page; the token identifies the end user
  on whose behalf the quoting/application flow is mounted. Ladder does not
  publish an OpenAPI document, an OAuth authorization server, or an OIDC
  discovery document (both /.well-known/oauth-authorization-server and
  /.well-known/openid-configuration return 404), and full reference credentials
  are issued only after a partner access request is approved. No scope surface is
  published, so no scopes/ artifact is asserted.
summary:
  types:
  - bearer-token
  api_key_in: []
  oauth2_flows: []
  public_spec: false
  access_model: partner-request
schemes:
- name: userToken
  type: bearer-token
  location: client-side constructor argument
  issued_by: partner backend
  evidence: >-
    Published integration snippet on https://www.ladderlife.com/api —
    "// obtain user auth token from your server" then
    "const ladderAPI = new LadderAPI(userToken);"
  sources:
  - https://www.ladderlife.com/api
notes:
- Reference documentation for server-side credentials is gated behind "Request access".
- No published OAuth 2.0 or OpenID Connect surface as of this probe.