generated: '2026-08-12'
method: searched
source: https://leadpages.com/developers/docs
versioning:
  scheme: none-published
  current: null
  docs: null
  note: >-
    No version segment appears in any documented path (/api/pages, /api/sites, …), no
    version header is documented, and no dated release train is published. Consumers have
    no way to pin a version.
deprecation:
  policy_url: null
  policy_published: false
  sunset_header: unknown
  note: >-
    No deprecation policy, no RFC 8594 Sunset/Deprecation header support documented, and
    no deprecation notices anywhere in the developer documentation. No Deprecation pointer
    is wired in apis.yml because there is no policy to point at.
changelog:
  url: null
  published: false
  probe: {url: 'https://leadpages.com/changelog', status: 404}
  note: >-
    No API or product changelog is published. The platform is described in llms.txt as
    "rebuilt from scratch in 2026", which makes the absence of a change record more
    consequential than usual — there is no public record of what moved in that rebuild.
sla:
  url: https://leadpages.com/security
  uptime_target: 99.9%
  claim_verbatim: >-
    99.9% Uptime SLA — Our infrastructure is designed for high availability with automated
    failover, health checks, and zero-downtime deploys.
  note: >-
    Stated on the security page as an infrastructure claim. No SLA contract document, no
    credit/remedy schedule and no measured historical uptime is published.
status_page:
  url: null
  published: false
  note: >-
    status.leadpages.com exists in DNS and resolves to Atlassian Statuspage
    (v71vlyntykqc.stspg-customer.com), but the page is INACTIVE — it redirects to
    https://leadpages.statuspage.io/inactive and renders "This page is currently inactive
    and can only be viewed by team members." The provider has provisioned a status page
    and not turned it on. No StatusPage pointer is wired in apis.yml, because there is no
    status information a customer or agent can actually read.
  probe: {url: 'https://status.leadpages.com/', status: 200, effective_url: 'https://leadpages.statuspage.io/inactive', verdict: inactive}
maturity:
  developer_portal_state: >-
    https://leadpages.com/developers markets the API and MCP server but its resource links
    render as "Coming Soon"; the substantive documentation lives at /developers/docs and
    /developers/mcp, both of which are live and detailed.
  company_history:
    founded: 2012
    rebuilt: 2026
    parent: Redbrick
    sibling_brand: HTML Pub (htmlpub.com)
    source: https://leadpages.com/llms.txt
host_health:
- host: api.leadpages.com
  role: documented REST base URL
  status: not-serving
  detail: >-
    Resolves via CNAME to ghs.googlehosted.com but does not complete a TLS handshake
    (curl error 35, SSL_ERROR_SYSCALL). Every REST example in the published documentation
    targets this host, so the documented quickstart cannot be run as written. This looks
    like a dangling DNS record left pointing at Google-hosted infrastructure.
- host: mcp.leadpages.com
  role: MCP server
  status: serving
  detail: TLS 1.3, returns 401 to unauthenticated tools/list — behaving as expected.
- host: leadpages.com
  role: website, discovery documents, MCP alias, A2A endpoint
  status: serving
  detail: TLS 1.3, HSTS max-age 31536000.
deprecated_operations: []
x-evidence:
  fetched: '2026-08-12'
  probes:
  - {url: 'https://status.leadpages.com/', status: 200}
  - {url: 'https://leadpages.com/changelog', status: 404}
  - {url: 'https://leadpages.com/roadmap', status: 404}
  - {url: 'https://leadpages.com/security', status: 200}
  - {url: 'https://api.leadpages.com/', status: 0}