generated: '2026-08-12'
method: searched
source: https://leadpages.com/developers/docs
docs: https://leadpages.com/developers/docs
note: >-
  Derived from the provider's own developer documentation and its RFC 8414 /
  RFC 9728 discovery documents, not from an OpenAPI — Leadpages publishes no
  OpenAPI of its own. The spec served at https://leadpages.com/openapi.json
  belongs to HTML Pub, a sibling brand, and was deliberately not used as a source
  here (see conventions/leadpages-conventions.yml).
summary:
  types: [http, oauth2]
  http_schemes: [bearer]
  api_key_in: [header]
  oauth2_flows: [authorizationCode]
  pkce: true
  dynamic_client_registration: true
schemes:
- name: bearerAuth
  type: http
  scheme: bearer
  in: header
  parameter: Authorization
  format: "Bearer lp_<api_key>"
  key_prefix: lp_
  description: >-
    API key issued from account dashboard settings, sent as a bearer token on every
    request. Documented as "best for server-to-server integrations", scoped to the
    account.
  availability: Pro plan and above (per the docs; the machine-readable pricing at
    /pricing.md marks "API access" as Yes on Pro, Business, Grow, Optimize and Scale,
    and No on Starter)
  sources: [https://leadpages.com/developers/docs]
- name: oauth2
  type: oauth2
  description: >-
    OAuth 2.0 authorization-code flow with PKCE, used for the MCP server and
    user-facing integrations. Documented as "no credentials shared with third
    parties"; tokens refresh automatically.
  availability: all plans, including the free trial
  flows:
  - flow: authorizationCode
    authorizationUrl: https://leadpages.com/api/mcp/oauth/authorize
    tokenUrl: https://leadpages.com/api/mcp/oauth/token
    registrationUrl: https://leadpages.com/api/mcp/oauth/register
    code_challenge_methods: [S256]
    grant_types: [authorization_code, refresh_token]
    token_endpoint_auth_methods: [client_secret_post]
    scope_count: 11
    scopes_ref: scopes/leadpages-scopes.yml
  sources:
  - https://leadpages.com/developers/docs
  - https://leadpages.com/.well-known/oauth-authorization-server
docs_endpoints:
  documented_in_docs_page:
  - POST /oauth/authorize
  - POST /oauth/token
  discovered_in_metadata:
  - https://leadpages.com/api/mcp/oauth/authorize
  - https://leadpages.com/api/mcp/oauth/token
  - https://leadpages.com/api/mcp/oauth/register
  discrepancy_note: >-
    The docs page shows bare "/oauth/authorize" and "/oauth/token" paths while the
    RFC 8414 metadata publishes them under /api/mcp/oauth/. Both are recorded; the
    metadata document is the machine-readable authority.
observed:
- {url: 'https://mcp.leadpages.com/mcp', unauthenticated_status: 401, body: '{"error":"Unauthorized"}'}
- {url: 'https://leadpages.com/api/a2a', unauthenticated_status: 401, body: '{"error":"Unauthorized"}'}
- note: >-
    Both agent surfaces reject anonymous calls with a bare JSON {"error":"Unauthorized"}
    and no WWW-Authenticate challenge pointing at the protected-resource metadata,
    so RFC 9728 discovery is published but not advertised on the 401 itself.
x-evidence:
  fetched: '2026-08-12'
  probes:
  - {url: 'https://leadpages.com/developers/docs', status: 200}
  - {url: 'https://leadpages.com/.well-known/oauth-authorization-server', status: 200}
  - {url: 'https://mcp.leadpages.com/mcp', status: 401}