STIX 2.1 & TAXII 2.1.
Standard objects over a standard transport, so a SOAR or SIEM consumes OmniIntel without a bespoke translation layer.
Why it matters
Every threat-intel platform can export JSON. The point of STIX is that the shapes are agreed, so your SOAR already knows what an indicator pattern is and does not need a per-vendor adapter. Native means we store and emit those shapes rather than mapping to them on the way out.
Objects we emit
| STIX type | From | Notes |
|---|---|---|
indicator | indicators | With a STIX pattern and confidence 0–100 |
vulnerability | vulnerabilities | CVE name, with CVSS/EPSS as extensions |
threat-actor | actors | Canonical name plus aliases |
malware | malware | Family level |
attack-pattern | attack_patterns | MITRE ATT&CK technique |
Bundle export
curl "https://api.omniintel.example/v1/stix/bundle\
?types=indicator,cve&limit=500&since=2026-07-01T00:00:00Z" \
-H "Authorization: Bearer $OMNI_INTEL_KEY"
< content-type: application/stix+json; charset=utf-8
< x-omni-stix-counts: {"indicator":412,"cve":88}
< x-omni-stix-generated-at: 2026-07-30T04:12:08.114Ztypes— comma-separated, from indicator, cve, actor, malware, ttp. Unrecognised types are rejected rather than ignored.limit— clamped between 1 and 5000, defaulting to 500.since— ISO 8601. This is how you do an incremental pull.
x-omni-stix-counts gives per-type counts without parsing the body, and x-omni-stix-generated-at gives the generation timestamp — useful as the high-water mark for your next since.
Counts without the bundle
GET /v1/stix/counts returns per-type totals as JSON without generating a bundle — cheap enough to poll when you only need to know whether anything changed.
Incremental pulls
The intended loop: record x-omni-stix-generated-at from each response, then pass it as since next time. That gives you only what changed, and it is idempotent — re-running with the same since returns the same set.