generated: '2026-08-13'
method: searched
source: >-
  https://developers.cognism.com/ , the Cognism help centre API articles, https://cognism.statuspage.io
  and https://status.cognism.com — all probed live on 2026-08-13
description: >-
  Cognism's API lifecycle posture is thin and, in two places, actively broken. There is no version
  identifier a client can pin, no deprecation or sunset policy, no published SLA, and the status page
  exists but is switched off. What Cognism does do well is migration communication: when it replaced
  the previous API it published a migration guide rather than breaking clients silently.

versioning:
  scheme: none
  current: null
  in_path: false
  in_header: false
  docs: null
  note: >-
    No /v1/ segment, no version header, no dated version. All endpoints sit at
    /api/search/... unversioned. A breaking change would arrive with nothing for a client to pin to.
  generational_change:
    described_as: 'the new Cognism API'
    evidence: >-
      The collection description contrasts a "new Cognism API" against the previous one — reduced
      search complexity, simplified data structure, faster responses, better technology and event
      search accuracy, configurable response fields, and removal of the old 10,000-displayed-results
      cap. Cognism also published a "Cognism API Migration Guide" help centre article.
    note: >-
      A real generational migration, communicated — but neither generation is labelled with a version
      string in the interface itself.

deprecation:
  policy_url: null
  policy_published: false
  sunset_header: false
  deprecation_header: false
  rfc8594: false
  note: >-
    No deprecation policy, no notice window, no RFC 8594 Sunset/Deprecation header support documented
    or observed. NOT wired as type Deprecation in apis.yml — there is no policy to point at.

sla:
  url: null
  uptime_target: null
  published: false
  note: >-
    No public SLA or uptime commitment. Terms are per enterprise contract; the public
    terms-of-website-use page carries no service-level commitment.

status_page:
  url: null
  probed:
  - {url: 'https://cognism.statuspage.io', status: 200, verdict: inactive}
  - {url: 'https://status.cognism.com', status: 500, verdict: broken}
  published: false
  note: >-
    Cognism PROVISIONED an Atlassian Statuspage and then left it off. cognism.statuspage.io answers
    200 with "Cognism Status - Page Inactive … This page is currently inactive and can only be viewed
    by team members", and its /api/v2/summary.json returns 401. The vanity host status.cognism.com
    returns a 500. Neither is a usable status page for a customer or an agent.
    NOT wired as type StatusPage in apis.yml — a 200 that says "inactive" is not a status page, and
    crediting it would be exactly the soft-200 false positive this pipeline exists to avoid.
  remediation_for_provider: >-
    Switch the existing Statuspage to public and repoint the status.cognism.com CNAME. The
    infrastructure is already paid for; only the visibility flag is wrong.

changelog:
  url: null
  published: false
  note: >-
    No dated public changelog or product-updates feed. /changelog and /product-updates both 404 on
    www.cognism.com, and the Postman collection carries no release notes. API changes surface only
    as help-centre article revisions. No changelog/ artifact is written for this provider.

support:
  channel: https://help.cognism.com/hc/en-gb
  escalation: >-
    Cognism Support, via the account. The troubleshooting article asks for the endpoint, HTTP status
    code and complete error response body — there is no request-ID to quote.

credentials:
  token_ttl: 6 months
  rotation: >-
    Self-service. Tokens are created and deleted in the Cognism app under Settings > Tokens and API;
    each carries a created date and an expiry date. Expired tokens stop authenticating with no grace
    period documented, so rotation must be scheduled by the consumer.

deprecated_operations: []

maintainers:
- FN: Kin Lane
  email: kin@apievangelist.com