API changelog.

Last updated 18 Sept 20266 min read

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-09-18: list pages hold at most 25 records

Changed

Every paginated endpoint now returns at most 25 records per page. The default was 100 and the maximum 500. A ?page_size= above 25 is clamped to 25 rather than rejected, so a request that asked for more still succeeds and comes back with a shorter page, plus a next link if there are more records.

The promise at the top of this page says a change like this ships under a new version prefix, announced here with a sunset date first. This one did neither. It went live in v1 on 2026-09-18, and this entry follows it. We are sorry for the missing notice.

What it means for an existing integration: if you walk result sets by following next until it is null, as Pagination and errors describes, your integration keeps working and returns the same complete set. It simply makes more requests to get there. Each page is a separate request and costs the list endpoint's credit price (1 credit for the list endpoints in Rate limits and credits), so a full walk now uses more credits and more of your per-minute rate limit than it did at the old page sizes. Check X-Credits-Remaining if you sync large sets on a schedule.

If your code reads only the first page and treats it as the whole answer, it now sees at most 25 records. Follow next to get the rest.

The cursor mechanism, the response envelope, authentication, credit costs per endpoint and error responses are unchanged.

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.

Was this page helpful?

← PreviousEnumerations Next →User roles and permissions