generated: '2026-07-24'
method: derived
source: >-
  Documented Limepay authentication model as captured in apis.yml (developer
  portal docs.limepay.com.au now gated behind a Redocly login, so no live spec
  could be re-fetched). No OpenAPI available to run derive-authentication.py
  against; profile hand-derived from the historically public documentation.
summary: >-
  Limepay used three scoped API keys, each presented as an HTTP Bearer token.
  A Publishable key authorised frontend/checkout calls, a Secret key authorised
  server-to-server Payments API calls, and a Platform key authorised
  administrative marketplace/onboarding calls on the Platform API.
schemes:
- id: publishable_key
  type: http
  scheme: bearer
  in: header
  header: Authorization
  format: 'Bearer <publishable_api_key>'
  audience: frontend / Checkout (browser-safe)
  applies_to: Limepay Checkout, client-side order/payment initiation
- id: secret_key
  type: http
  scheme: bearer
  in: header
  header: Authorization
  format: 'Bearer <secret_api_key>'
  audience: server-to-server
  applies_to: Payments API (create/pay orders, capture/void, refunds, saved cards)
- id: platform_key
  type: http
  scheme: bearer
  in: header
  header: Authorization
  format: 'Bearer <platform_api_key>'
  audience: platform administration
  applies_to: Platform API (sub-merchant onboarding, KYC, settlement reports, platform refunds)
oauth2: false
openid_connect: false
mutual_tls: false
notes: >-
  Keys were issued per environment (test vs live). No OAuth2/OIDC flow was
  documented; authorization is a static bearer API key with resource scope
  determined by which key is used.