Endpoint
https://api.recordedfuture.com/taxii2
The service implements parts of the RESTful interface defined by the TAXII Version 2.1 standard and returns data in STIX 2.1 JSON format. Interactive API documentation is available at api.recordedfuture.com/taxii2/docs.
Authentication
HTTP Basic Auth as specified by the TAXII 2.1 standard:
- Username: empty string
- Password: your Recorded Future API token
curl -u ":YOUR_API_TOKEN" \
-H "Accept: application/taxii+json;version=2.1" \
https://api.recordedfuture.com/taxii2/Available endpoints
| Endpoint | Description |
|---|---|
Server Discovery (/taxii2/) | Returns server info and available API roots |
Get API Root Information (/taxii2/{root}/) | Title, description, and supported TAXII versions for a root |
Get Collections (/taxii2/{root}/collections/) | Lists all collections available under an API root |
Get a Collection (/taxii2/{root}/collections/{id}/) | Details for a specific collection |
Get Objects (/taxii2/{root}/collections/{id}/objects/) | Returns STIX 2.1 indicator objects from the collection |
Only read operations are supported. The max_content_length attribute of a root relates to write operations and can be ignored.
API roots
API roots are logical groupings of collections. Each root controls the maximum number of objects returned.
| Root | Max objects | Purpose |
|---|---|---|
default | 100,000 | Standard risk lists — equivalent to "default" downloadable risk lists |
large | 1,000,000 | Extended risk lists with a lower risk threshold — more indicators, broader coverage |
opencti | 1,000 | Formatted for OpenCTI compatibility — flattened EvidenceDetails in labels, smaller collections |
test | 10 | Minimal collections for integration testing |
The default and large roots correspond to the default and large risk lists available through the Connect API and Fusion file downloads.
Collections
Each API root contains 5 collections, one per IOC type:
| Collection | IOC Type | STIX Object Type |
|---|---|---|
| Cyber vulnerabilities | CVEs | vulnerability SDO |
| Internet domain names | Domains | indicator SDO |
| IP addresses | IPv4 addresses | indicator SDO |
| Hashes | File hashes (MD5, SHA-1, SHA-256) | indicator SDO |
| URLs | Malicious URLs | indicator SDO |
To list collections for a root:
curl -u ":YOUR_API_TOKEN" \
-H "Accept: application/taxii+json;version=2.1" \
https://api.recordedfuture.com/taxii2/default/collections/Pagination
When requesting objects, use the limit query parameter to control response size.
| Parameter | Value |
|---|---|
| Default limit | 1,000 objects |
| Maximum limit | 1,000 objects |
The default and maximum limit was reduced from 5,000 to 1,000 on May 15, 2025, for load and performance optimization, per TAXII 2.1 specification sections 3.4 and 3.5.
If more objects exist beyond the limit, the response includes a more: true flag and a next token. Pass the next value in subsequent requests to paginate through the full collection:
curl -u ":YOUR_API_TOKEN" \
-H "Accept: application/taxii+json;version=2.1" \
"https://api.recordedfuture.com/taxii2/default/collections/{id}/objects/?limit=1000&next={token}"STIX 2.1 object structure
Each response contains an array of STIX 2.1 objects. Indicator objects include:
| Field | Description |
|---|---|
name | Human-readable indicator name (e.g., "IP Address 188.227.14.105") |
description | Risk summary (e.g., "Current risk: Very Malicious. Triggers 10 of 87 risk rules") |
confidence | Risk score (0–99) |
pattern | STIX pattern expression (e.g., [ipv4-addr:value = '188.227.14.105']) |
indicator_types | Risk criticality label (e.g., very-malicious) |
labels | JSON-encoded EvidenceDetails — lists each triggered risk rule with its criticality |
valid_from / valid_until | Time window for the indicator's validity |
OpenCTI root note: In the opencti root, the EvidenceDetails tree structure is flattened into the labels field, since OpenCTI has issues handling nested structures.
Requesting updated objects
Collections are generated as a snapshot at request time. All indicator objects share the same created and modified timestamps, so the added_after filter parameter has no effect on response sizes.
