Our CTI Now Talks STIX 2.1 Over a Real TAXII 2.1 Server
We kept getting the same question from members running MISP or OpenCTI: "can we just pull this over TAXII instead of hitting your REST API?" So we built it. Discovery, collections, pull, and — new this release — push, all in STIX 2.1.
Most of the Alliance's data has always been reachable through our own REST endpoints, and honestly that's still the fastest way to get a Crime Score for a single IP. But if you already run a threat intel platform — MISP, OpenCTI, Anomali, ThreatConnect, whatever your team standardised on — those tools expect to speak STIX 2.1 over TAXII 2.1, not a bespoke JSON schema. Writing and maintaining a custom parser for every member's platform doesn't scale, and it's the kind of integration work nobody enjoys doing twice.
So instead of asking every member to adapt to us, we adapted to the standard everyone else already built for. The server sits alongside the existing REST API and the older STIX 2.0 endpoint — nothing was ripped out, we just added the plumbing most CTI tooling already expects.
What's Actually There
Standard TAXII 2.1 discovery-to-object walk. If your client already talks TAXII, this should just work — that was the point.
added_after, limit, next.
{
"objects": [
{
"type": "indicator",
"spec_version": "2.1",
"id": "indicator--7f3c...a91e",
"created": "2026-08-01T22:04:11Z",
"modified": "2026-08-02T06:12:47Z",
"pattern": "[ipv4-addr:value = '185.220.101.45']",
"pattern_type":"stix",
"valid_from": "2026-08-01T22:04:11Z",
"indicator_types": ["malicious-activity"],
"confidence": 94,
"labels": ["tor-exit", "brute-force"]
}
],
"more": true,
"next": "eyJvZmZzZXQiOiAyNTB9"
}
Pulling and, Now, Pushing
Reading (pull)
Every object gets a deterministic STIX ID, so re-pulling the same feed twice won't leave you with duplicate indicators — dedup is basically free on your end. IPv4 indicators decay over time as context ages; domains, URLs and hashes hold their score. Pagination follows the standard added_after / limit / next pattern, nothing bespoke to learn.
Writing (push) — new
Collections now accept up to 50 STIX 2.1 Indicators per POST. Submissions run through the same validation pipeline as our REST API, and you get a per-object success/failure status back — it won't silently accept garbage, and it won't reject the whole batch because one object was malformed.
Auth & access
Reuses whatever credentials you already have with OneFirewall — Bearer JWT or HTTP Basic. Reading is metered against your token balance the same way REST calls are; discovery calls are free. Needs an org plan with Threat Intel access.
Still there: STIX 2.0
If you've got something older pointed at GET /stix2/{stix2id} on the REST API, it's untouched — pass an IP (mainly), domain, URL, or hash and get back a STIX 2.0 bundle. We're not forcing a migration on anyone; TAXII 2.1 is the better path going forward, but the old lookup endpoint isn't going anywhere yet.
Who This Is Actually For
Mostly people who already have a TAXII-speaking platform and don't want a one-off integration to maintain.
MISP / OpenCTI users
Add us as a TAXII 2.1 feed source directly — no export/import step, no custom parser to write and babysit.
SOC teams sharing back
Push what you found via the same collection — it lands in the same consensus pipeline as everything else the Alliance sees.
Anyone scripting a feed sync
The pagination and object model are standard enough that most existing TAXII client libraries just work against it unmodified.
Point Your TAXII Client at Us
Grab the endpoint list and auth details from the docs, or just ask us — we'd rather answer a "does this work with X" question up front than have you find out the hard way.