API changelog.

Our compatibility promise

Within v1 the contract only grows. We add fields and endpoints; we do not rename or remove them. An integration reading a field today will find it there tomorrow.

Two consequences to design for:

• Ignore fields you do not recognise. New ones appear without notice.
• Do not depend on key order or on the absence of a field.

If a genuinely breaking change ever becomes necessary, it ships under a new version prefix and the old one is announced here with a sunset date first.

---

2026-08-12: per-vendor IOC enrichment, source icons, and leak-site claims

Six new IOC-enrichment providers and a ransomware leak-site feed shipped in the platform. Everything below is additive.

New

• Per-vendor enrichment on /iocs/: enrichment_providers, a sorted list of the providers that have enriched an indicator, and enrichments, one entry per provider carrying that vendor's own verdict and a short detail. Both appear on the list, lookup and export responses. The provider codes are on Enumerations.
• source_module on IOCs, naming the module an indicator first arrived through, which is how you find indicators derived from a particular feed.
• ?enrichment_provider= on /iocs/ and /iocs/export/, so you can ask for everything one vendor flagged. An unrecognised value is a 400 naming the field.
• enrichment_providers in the IOC CSV export, pipe-joined, appended as the last column.
• source_icon_url on the nested report block of /events/ and on each row of a Threat Event's sources[]. An absolute URL to the source's icon, null where none resolves, so a dashboard built on the API no longer needs its own logo table.

Changed

• verdict and confidence now reflect six additional vendors for accounts that enable them: URLScan, GreyNoise, Shodan, AbuseIPDB, Censys and ReversingLabs. Nothing about the response shape changed, but the values move once a key is saved. Two semantics are worth reading before you build on them: UNKNOWN is not a weak BENIGN, and verdicts only escalate.
• "Ransomware.live" is a new module value on /events/ and on Threat Event sources, carrying ransomware leak-site victim claims at reliability B. The grade describes the aggregator, not the truth of the claim.

Fixed

• Nothing in this release.

Notes for existing integrations

• CSV consumers should read by header. enrichment_providers is appended after last_seen, so a parser reading the first nine columns by position is unaffected, and the existing nine columns were deliberately left in place rather than reordered. A parser that asserts a column count will need the new width.
• Ransomware domain-hit alerts are not AlertRules and do not appear under /alerts/. Consume them through a webhook destination; the payload is documented there.
• Enrichment provider credentials remain configurable in the app only, and are never readable or writable over the API.

---

2026-07-29: Threat Events, the canonical catalog, and search

The largest change since launch. The API previously exposed a report-per-item feed and a per-account entity list; it now exposes the deduplicated occurrence layer and the canonical catalog that the platform itself runs on.

New

• /threat-events/: deduplicated occurrences with their sources, each source's stance and Admiralty reliability grade, the occurrence's credibility band and verification stage, linked entities and ATT&CK techniques, and per-organization relevance. Requires the new threat-events.read scope.
• /threat-events/{id}/iocs/, /iocs/export/, /stix/: indicators for an occurrence, and parented STIX 2.1 bundles that carry the occurrence plus relationships to each indicator (unlike the flat /iocs/export/ bundle).
• /search/: the platform's own search engine, returning Threat Events. Supports flat criteria and boolean query_tree condition groups. Requires the new search.read scope.
• /searches/ and /searches/{id}/run/: read and run your account's saved searches.
• /threat-library/{type}/{id}/ sub-resources for dated ATT&CK technique observations, linked occurrences, co-occurring entities, IOCs and STIX.
• threat_event_id on every row of /events/, plus report_type, report_subtype, module and reliability on the nested report, and ?threat_event= / ?since= filters.
• Alert rules now carry the criteria they match on.

Changed

• /threats/{type}/ is now /threat-library/{type}/, and reads the canonical catalog rather than your account's private entity rows. Entries gained aliases, origin, actor_kind, attack_id, target sectors and countries; vulnerabilities gained cve_id, CVSS, EPSS, KEV status and CWE ids. Your account's own view of an entry moved into a tracking object. ?alias= resolves a vendor's name for an actor to the canonical entry.
• /alerts/{id}/matches/ returns Threat Events rather than individual reports, matching search and the rest of the platform. Pass ?results=reports for the previous shape.
• /alerts/ and every /organizations/* list are now paginated. They were the exception to the documented pagination model.
• enrichment_status on /events/ is validated. An unrecognised value is now a 400; it previously returned an empty page with a 200.

Fixed

• /events/ingest/ now accepts text. The documented field name was never read by the API, so a request following the documentation created a report with an empty body. Both text and description are accepted.
• IOC confidence is consistent across formats. /iocs/ and /iocs/export/?format=csv returned a stored value while ?format=stix returned the derived one; all three now return the derived value the platform shows, and null/empty when there is no signal.
• ?since= with an impossible date returns 400 rather than failing with a server error.
• Ingest now returns "status": "accepted" as documented, and validates that title is present.

Notes for existing integrations

No customer keys were in use when this shipped, so nothing was broken in production. If you built against a pre-release copy of the docs: repoint /threats/ to /threat-library/, expect Threat Events from /alerts/{id}/matches/ unless you pass ?results=reports, and follow the next link on the alert and organization lists.