The query is classified first, and only the stores that could plausibly match it are queried — a SHA-256 doesn't trigger a pointless URL scan. The classification is returned as detected so you can see how your input was read.

Query parameters

What each query type searches

curl -G https://api.threatera.eu/api/search \
  -H "x-api-key: $THREATERA_KEY" \
  --data-urlencode "q=invoice"

{
  "query": "invoice",
  "detected": "text",
  "files":      {"total": 2, "results": [ … ]},
  "indicators": {"total": 0, "results": []},
  "urlscans":   {"total": 1, "results": [{"id":"…","url":"…","status":"completed","created_at":"…"}]},
  "total": 3
}

URL scans come back in a reduced shape here; fetch GET /urlscans/{id} for the full record.

Upload a file. Stores the raw bytes, records metadata, and indexes it for search.

Form fields (multipart/form-data)

curl -X POST https://api.threatera.eu/api/files/upload \
  -H "x-api-key: $THREATERA_KEY" \
  -F "file=@sample.bin" \
  -F "scan_type=deep" \
  -F "tags=malware,emotet"

{
  "message": "File uploaded successfully",
  "filename": "sample.bin",
  "queued": ["static_analysis", "detonation"]
}

Look up a file's intel record by hash. 404 if never seen.

{
  "hash": "8d0a…a255", "filename": "invoice.sh",
  "content_type": "application/octet-stream", "size": 200440,
  "tags": ["email"], "verdict": "clean", "yara_matches": [],
  "ingested_at": "2026-07-20T08:49:24Z", "last_seen": "2026-07-20T08:49:24Z",
  "counter": 1,
  "detonation": { "supported": true, "reason": "" },
  "provenance": {
    "extracted_from": "bebc…8ac9",
    "extracted": []
  }
}

detonation answers "can the sandbox run these bytes?" from the stored object itself, so a client can disable the action before any analysis exists. reason is the server's own wording for why not.

provenance is both directions of the extraction relationship, scoped to your organisation:

Search ingested files, most recently seen first. All filters are optional and combine with AND.

Query parameters

curl "https://api.threatera.eu/api/files?tag=malware&seen_since=2026-06-01&limit=20" \
  -H "x-api-key: $THREATERA_KEY"

Returns { "total": n, "results": [ FileRecord, … ] }.

The distinct content types actually present in the store, most common first — the valid values for the content_type filter above, so a client can offer a dropdown instead of asking the user to guess a MIME type.

Returns { "content_types": ["application/octet-stream", "text/plain", … ] }.

Download the raw stored bytes. Always served as application/octet-stream with an attachment disposition — a stored sample is never rendered or executed inline.

curl https://api.threatera.eu/api/files/<sha256>/raw \
  -H "x-api-key: $THREATERA_KEY" -o sample.bin

Record what an analyst concluded about this file. This is a second verdict and it does not touch the first.

verdict on the file record is the machinery's answer — ClamAV, YARA, capa, the sandbox — and re-analysis is free to change it. This is a named person's judgement at a moment, and it has to survive exactly that. The two are stored and returned separately so a disagreement between them stays visible instead of one silently overwriting the other.

Body (application/json)

curl -X PUT https://api.threatera.eu/api/files/<sha>/verdict \
  -H "x-api-key: $THREATERA_KEY" -H "content-type: application/json" \
  -d '{"verdict":"false_positive","note":"signed internal build, ships with the VPN client"}'

Which verdict should a client use? Where a person is being shown a conclusion, prefer analyst_verdict when it is set and fall back to verdict. Anything leaving the platform — a STIX bundle, a regulatory filing — uses verdict, because it is the reproducible one and its reader cannot see the note behind a human's.

analyst_verdict: null means nobody has looked. It is not a verdict of unknown, and it is the triage state the Files queue is worked down.

404 if your organisation does not hold the file. Holding it is the question — a hash another customer has analysed is not yours to judge.

The same analyst conclusion about several files. Triage produces this shape of work: a rule fires on forty files from one campaign and every one of them gets the same answer.

{ "decided": 37, "missing": ["<sha>", "<sha>", "<sha>"] }

It reports what it did, not that it succeeded. decided is the number of rows actually written and missing names hashes your organisation does not hold. A caller that selected forty and changed thirty-seven has to be able to tell — reporting blanket success is how a bulk control loses somebody's work without either of you noticing.

Queue static analysis (hashes, entropy, type, PE/ELF internals, archive members, Office macros, string & IOC extraction, ClamAV + YARA verdict). Returns 202 with a pending analysis; poll the analysis endpoint.

Body (application/json, optional)

curl -X POST https://api.threatera.eu/api/files/<sha>/analyze \
  -H "x-api-key: $THREATERA_KEY" -H "content-type: application/json" \
  -d '{"archive_password":"infected"}'

The most recent analysis for a file. 404 if none has run.

{
  "status": "completed",
  "result": {
    "file_type": "pe", "size": 51200, "entropy": 7.91,
    "md5": "…", "sha256": "…", "imphash": "…", "tlsh": "…",
    "verdict": "malicious",
    "detections": { "clamav": {"status":"infected","signature":"Win.Trojan.Emotet"},
                     "yara": {"status":"ok","matches":["c2_beacon"]} },
    "iocs": [{"type":"domain","value":"evil-c2.example.com"}],
    "pe": { /* sections, imports, exports, signed, packing… */ }
  }
}

A PE file gets a pe block; an ELF an elf block; an archive an archive block (with members); a macro-enabled Office doc a macros block.

Queue dynamic detonation — actually execute the sample in a locked-down, throwaway container and capture behavior. Returns 202. If the file type isn't supported, the record comes back status: "unsupported" with an error and nothing is queued.

Two backends, chosen from the file's own bytes and reported on the record as backend:

Query parameters

curl -X POST "https://api.threatera.eu/api/files/<sha>/detonate?network=sinkhole" \
  -H "x-api-key: $THREATERA_KEY"

What an API trace reports

Not the raw firehose. A full relay trace is millions of lines and a slowdown of one to two orders of magnitude, so the trace is scoped at the source to a curated set of functions — file, registry, process, network, crypto, service, loader and anti-analysis. The result carries three things: counts per category, the named behaviours that no single call demonstrates (process injection is WriteProcessMemory and CreateRemoteThread; either alone is ordinary), and the calls themselves with their string arguments — the path written, the URL fetched, the value set.

The run's packet capture, as a pcap file — open it in Wireshark, replay it through Suricata or Zeek, keep it as evidence on a case.

These are the bytes tcpdump wrote, unmodified. The network summary on the detonation report is read back out of this same file rather than captured separately, so the download and the report cannot disagree about what crossed the wire.

curl "https://api.threatera.eu/api/detonations/42/pcap" \
  -H "x-api-key: $THREATERA_KEY" -o run-42.pcap

404 when the run captured nothing: network=none, a run that failed before the capture started, or any detonation from before captures were kept. Very chatty samples stop at 100,000 packets — the file stays a valid capture, and the report says when the limit was reached.

What is inside a stored archive, and which members could be detonated. Use it to choose an entry_point for POST /files/{hash}/detonate.

One file per run misses the samples that need their siblings — a signed executable beside the DLL it side‑loads does nothing interesting on its own, and a script that reads a config from its own folder fails without it. Naming a member runs that member with the whole archive laid out around it.

{
  "hash": "9f2b…",
  "members": [
    { "name": "app.exe", "size": 184320,
      "detonable": true, "backend": "windows_wine", "reason": "" },
    { "name": "version.dll", "size": 51200,
      "detonable": false, "backend": null,
      "reason": "The sandbox cannot execute 'unknown' files…" },
    { "name": "data/config.ini", "size": 82,
      "detonable": false, "backend": null, "reason": "This is a text file, but…" }
  ],
  "truncated": false
}

detonable is answered per member by the same check the detonation itself uses, so the list cannot offer something the run would then refuse. backend follows the member, not the archive: the same zip runs under Wine when you pick a PE and on Linux when you pick a shell script.

Names are normalised the way the sandbox will normalise them, and an archive with an absolute or traversing path (../) is rejected outright with 400 — it is refused for the whole archive rather than skipped, because a member trying to write outside its own directory is a property of the archive worth knowing.

400 if the file is not an archive, or expands past the sandbox’s limits (512 members, 256 MB uncompressed). 404 if the file is unknown. Listing stops at 200 members with truncated: true.

The most recent detonation run for a file. 404 if none has run.

{
  "status": "completed", "backend": "linux_container", "network_mode": "sinkhole",
  "result": {
    "exit_code": 0, "timed_out": false, "duration_seconds": 0.42,
    "stdout": "…", "dropped_files": [{"path":"/tmp/x","kind":"added"}],
    "network": { "mode":"sinkhole", "dns_queries":["evil-c2.example.com"], "ports":[80] },
    "iocs": [{"type":"domain","value":"evil-c2.example.com"}]
  }
}

A windows_wine run carries two more keys in result:

{
  "status": "completed", "backend": "windows_wine",
  "result": {
    "dropped_files": [{"path":"C:\\users\\nobody\\Temp\\evil.exe","kind":"added"}],
    "registry_changes": [{
      "key": "HKEY_CURRENT_USER\\Software\\Microsoft\\Windows\\CurrentVersion\\Run\\Updater",
      "kind": "added", "value": "C:\\users\\nobody\\Temp\\evil.exe"
    }],
    "persistence": [{"mechanism":"registry-run", "description":"a Run key, which starts …"}],
    "fidelity": { "emulated": true, "note": "Run under Wine, not Windows. …" }
  }
}

registry_changes is a value-level diff against a pristine copy of the hives baked into the sandbox image — Wine rewrites all three hive files on every shutdown regardless of what happened, so a file-level comparison would report the whole registry as modified on every run. Per-machine identity that Wine rebuilds each start (computer name, Tcpip\Parameters\Hostname, volatile environment, driver timestamps) is excluded: it is the harness's, not the sample's.

Indicators extracted from this file (the file → IOC pivot). 404 if the file is unknown; an empty list if it has no indicators.

Files related to this one by TLSH fuzzy-hash distance and imphash. Optional query params: threshold (max TLSH distance, lower = stricter) and limit (corpus files to compare).

A single shareable report for a file — the intel record, detections, static analysis, extracted indicators and the sandbox detonation bundled into one document. This is the thing you attach to a ticket instead of screenshotting five panels.

Query parameters

Responds with text/markdown or application/pdf as a download (Content-Disposition: attachment), not JSON. 404 if the file is unknown.

curl -O -J "https://api.threatera.eu/api/files/8d0a…a255/report?format=pdf" \
  -H "x-api-key: $THREATERA_KEY"

Submit an indicator (type auto-detected). Re-submitting bumps the counter and refreshes last_seen. Non-routable / internal values are rejected with 400.

Body (application/json)

curl -X POST https://api.threatera.eu/api/iocs \
  -H "x-api-key: $THREATERA_KEY" -H "content-type: application/json" \
  -d '{"value":"185.220.101.1","tags":["c2","tor"]}'

Search indicators, most recently seen first. Filters combine with AND.

Query parameters

Look up a single indicator (type inferred). 404 if unseen.

{
  "type": "ip", "value": "185.220.101.1", "tags": ["c2","tor"],
  "first_seen": "…", "last_seen": "…", "counter": 5,
  "enrichment": {
    "network": {
      "asn": 60729, "as_org": "Stiftung Erneuerbare Freiheit",
      "country": "DE", "country_name": "Germany" },
    "feeds": [{
      "feed": "tor_exit", "name": "Tor exit nodes", "label": "tor exit node",
      "confidence": null, "reference": "https://…", "first_seen": "…" }],
    "intel": [{
      "source": "CERT-AT feed", "kind": "taxii", "label": "Emotet C2",
      "confidence": 80, "tlp": "amber", "reference": "indicator--…",
      "first_seen": "…" }]
  }
}

The enrichment blocks

Every one of them is answered locally. GeoIP reads a bundled database, feed and intel matches read tables this deployment already downloaded on a schedule. Nothing here asks a third party anything at lookup time, which is the whole point: opening an indicator is not audible to whoever runs the source. Absent blocks are omitted rather than sent empty, and enrichment itself is absent when there is nothing to add.

Files that reference this indicator (the IOC → file pivot). Each carries how:

Blocking decisions turn on which of these you have, and before this field existed the two were indistinguishable in the same row.

URL sandbox runs that contacted this indicator (the IOC → URL-scan pivot).

How often your organisation has met this indicator, day by day. ?days= sets the window (1–90, default 14).

The running counter on the indicator itself answers how significant is this and cannot answer is it getting worse. Four hundred sightings spread over a year is infrastructure somebody should have blocked long ago; four hundred that all arrived on Tuesday is an incident. The counter renders both as 400.

{
  "value": "c2.example.test",
  "days": [ {"day": "2026-08-16", "count": 0}, … {"day": "2026-08-29", "count": 37} ],
  "total_in_window": 91,
  "total": 412,
  "recording_since": "2026-08-20"
}

Three things worth reading carefully:

• The series is dense. Every day in the window is present, zeroes included, so a client can draw it without re-densifying a sparse list — which is where an off-by-one puts Tuesday's spike on Wednesday.
• recording_since is where the record begins. Per-day counting started with a migration and was deliberately not backfilled: the platform never recorded when a repeat sighting happened, only that the count went up, so any earlier history would be a distribution nobody observed. A zero before this date means "not counting yet", which is the opposite of what a zero after it means. Draw them differently.
• total_in_window is not total. They differ for any indicator older than the window. Reporting one as the other makes the chart look broken.

404 if the indicator is unknown to the platform.

DNS history. The direction depends on what you ask about, and the reverse case is the interesting one:

{
  "value": "93.184.216.34", "type": "ip", "direction": "ip_to_domain",
  "active_dns": { "status": "not_applicable" },
  "results": [{
    "domain": "example.com", "ip": "93.184.216.34", "count": 4,
    "source": "urlscan",
    "first_seen": "2026-07-14T10:02:11Z", "last_seen": "2026-07-26T18:44:03Z"
  }]
}

Live lookups

For a domain, the endpoint may resolve the name itself, and reports what it did in active_dns.status: disabled, cached (something was already observed within ACTIVE_DNS_CACHE_MINUTES), resolved, error, or not_applicable for an IP. A failed lookup is never recorded — "we could not ask" is not an observation.

400 if the value is not a valid IP or domain.

A risk score for an indicator, computed entirely from your own instance's data — the files that reference it and their verdicts, sandbox runs that contacted it, analyst tags, and registration age.

Response

{
  "value": "evil-c2.com", "type": "domain",
  "score": 75, "band": "malicious", "confidence": "high",
  "signals": [
    {"label":"extracted from malicious files","weight":45,"detail":"2 file(s) …"},
    {"label":"labelled by an analyst","weight":30,"detail":"tagged c2"}
  ],
  "evidence": {"linked_files":2,"malicious_files":2,"sandbox_runs":0, …},
  "basis": "Computed only from this instance's own data …"
}

Bands

An indicator with no evidence returns unknown, never benign. That distinction is the point: a confident "clean" on something the platform has never encountered would be inventing reassurance out of an empty database. likely-benign means it was examined; unknown means it wasn't.

The score is exactly the sum of the signals weights (clamped to 0–100), and every signal carries the evidence behind it — an analyst has to be able to disagree with the number, which means seeing what produced it. confidence reflects how much evidence exists, separately from what it concluded.

Registration data via RDAP — the structured successor to WHOIS. For a domain: registrar, registration/expiry/last-changed dates, nameservers and EPP status codes. For an IP: the allocated network range, organisation, country and abuse contact.

While disabled the endpoint still returns 200, with "enabled": false and an explanatory error — a turned-off feature is a state, not a failure. No network call is made.

Response

{
  "value": "example.com", "type": "domain",
  "enabled": true, "cached": true, "error": null,
  "registrar": "Example Registrar, Inc.",
  "registered_at": "1995-08-14T04:00:00+00:00",
  "expires_at": "2027-08-13T04:00:00+00:00",
  "nameservers": ["a.iana-servers.net", "b.iana-servers.net"],
  "statuses": ["client transfer prohibited"],
  "raw": "{…the registry's full RDAP response…}"
}

raw carries the complete registry response as a JSON string. The parsed fields above cover the common case, but registries put useful detail in fields nobody standardised — reseller, DNSSEC state, registrant hints — so this is where an analyst looks when the summary is not enough. Typically a few KB; hard-capped by RDAP_MAX_RESPONSE_BYTES. The UI shows it collapsed under the summary table.

Queries go to the authoritative registry, discovered through the IANA bootstrap — never through a public redirector such as rdap.org, so no aggregator learns what you look up.

Results are cached for RDAP_CACHE_DAYS (default 7). Failures are cached too: a TLD that publishes no RDAP service, or a domain that isn't registered, would otherwise be re-asked on every page view. cached: true tells you the answer came from that cache.

Coverage — read this before concluding it is broken

RDAP is mandatory for gTLDs (.com, .net, .org, .io, .dev, …) and those return full detail. It is voluntary for country-code TLDs, and many European registries either publish nothing or redact almost everything:

An empty or sparse panel for a European domain is therefore usually the registry's disclosure policy, not a failure here. Threatera does not fall back to port-43 WHOIS.

A slow, rate-limiting or malformed registry never fails the request — the reason arrives in error and the rest of the indicator page is unaffected.

Queue a sandboxed render. Returns 202 with a pending scan; poll the scan endpoint. A URL that resolves to internal/private space is rejected with 400.

Body (application/json)

curl -X POST https://api.threatera.eu/api/urlscans \
  -H "x-api-key: $THREATERA_KEY" -H "content-type: application/json" \
  -d '{"url":"https://example.com"}'

A URL sandbox run by id.

{
  "id": 31, "url": "https://example.com", "status": "completed",
  "result": {
    "final_url": "https://example.com/", "title": "Example Domain",
    "screenshot_object": "urlscans/31.png",
    "requests": [{"url":"…","method":"GET","status":200,"remote_ip":"…"}],
    "certificate": {"subject_cn":"example.com","issuer_cn":"…","not_after":"…",
                    "tls_version":"TLSv1.3","sha256":"…","sans":["example.com"]},
    "iocs": [{"type":"domain","value":"example.com"}]
  }
}

List URL scans, most recently submitted first. Params: url (prefix match), limit, offset, include_dismissed.

include_dismissed is true here, unlike GET /detonations: this endpoint also answers “has this URL been scanned”, and a scan somebody cleared out of the sandbox queue is still a scan of that URL. The sandbox list passes false.

The rendered page's screenshot (PNG). 404 if unavailable.

curl https://api.threatera.eu/api/urlscans/31/screenshot \
  -H "x-api-key: $THREATERA_KEY" -o shot.png

Download the captured TLS certificate as PEM. 404 if none was captured (not https, or the handshake failed).

curl https://api.threatera.eu/api/urlscans/31/certificate \
  -H "x-api-key: $THREATERA_KEY" -o cert.pem

Indicators (hosts/IPs) contacted during the scan.

Recent detonation runs, newest first — each with the file's hash and first-seen filename. Params: limit, offset, include_dismissed. Returns { "total": n, "results": [...] }.

include_dismissed is false by default: runs an analyst has cleared out of the sandbox queue are left out, and total counts the same set the page is drawn from. Pass true to see them. Note that GET /urlscans defaults the other way — it also answers “has this URL been scanned”, and a scan somebody set aside is still a scan of that URL.

Clear several sandbox runs out of the queue, or put them back. The sandbox list is the union of two endpoints, so each run is named by both halves of its identity:

{ "runs": [ { "kind": "file", "id": 41 }, { "kind": "url", "id": 9 } ], "dismissed": true }

kind is file (a detonation) or url (a URL scan); anything else is a 400 rather than a silent no-op, because this is the one place a client composes the pair by hand. dismissed defaults to true; send false to put runs back. Capped at 500 ids per kind.

Reports what it did rather than that it succeeded: dismissed counts the rows actually changed and missing names the ones that were not yours to touch, so a caller that selected forty and changed thirty-seven can tell.

{ "dismissed": 2, "missing": [] }

Submit several sandbox runs again. Same runs shape as above; returns 202.

Each detonation is repeated with its own network_mode, args and trace rather than with today's defaults — a run reproduced under different containment has not been reproduced. A re-run is a new run, never an edit of the old one, so “this failed on Tuesday and passed on Friday” stays readable.

{ "queued": ["file:112", "url:78"], "failed": [ { "run": "file:41", "reason": "the file is no longer stored" } ] }

failed names anything that could not be queued — an unknown run, a file this organisation no longer holds, or a sample that is no longer eligible.

A single detonation run by id (DetonationResponse).

The result carries a persistence list — the filesystem changes that would outlive the process, each with the mechanism and what it means. This is the answer to "is the host still compromised", as opposed to dropped_files, which is everything the sample wrote.

Each finding is also emitted as a Sigma event under the persistence category, so a rule can select on Mechanism instead of on a path list that drifts out of step with the sandbox.

Cases in your organisation, newest first. Params: status (open|monitoring|closed), assignee, q (matches reference, title or summary), sort, limit, offset. Each result carries item_count.

sort is field:asc or field:desc over created_at, updated_at, reference, title, status, assignee, item_count or severity. Severity orders by rank, not alphabetically — sorted as text, critical comes before low and high before medium, which produces a list that looks ordered and is wrong at the moment somebody is scanning it for the worst thing.

One case with its contents. Each item is resolved back to the live artefact at read time and returned with a label, a detail line and an href into the UI.

Apply the same change to several cases — closing a week's work, or handing a queue to somebody. Body: { "ids": [...], "status", "severity", "assignee" }, each field optional and applied only when sent.

{ "ids": [41, 42, 43], "status": "closed" }

Already in that state is not counted as a change. Closing four of twelve selected, because eight were closed already, reports four. closed_at is stamped on close and cleared on reopen rather than derived later: "how long was this open" is a number customers ask for, and reconstructing it from the audit log is fragile once events are ever pruned.

One audit entry for the batch, one event per case. The two want opposite things from the same action — a log read by a person is buried by twelve rows written in the same second, while an event sink is a machine tracking state, and a single summarising message would leave eleven cases stale downstream with nothing to reconcile against. Only status changes emit case.status_changed: a SOC routes on "this closed" and would mute a channel that also fired on a reassignment.

missing names ids that were not yours to touch. Capped at 500.

{ "changed": 4, "unchanged": 8, "closed": 4, "missing": [] }

Attach an artefact. Body: { "kind", "ref", "note" }.

409 if it is already attached — a repeat is a mis-click, and a silent no-op would look like the button did nothing. note is optional and is the most useful field here: why this artefact is part of this incident.

Attach several artefacts at once. Body: { "items": [ { "kind", "ref", "note" } ], "note" }, with the same kind vocabulary as above. The outer note applies to every link; a per-item note overrides it for that item.

{ "items": [ { "kind": "email", "ref": "41" }, { "kind": "email", "ref": "42" } ],
  "note": "same lure, same sender domain, reported within the hour" }

The same artefact named twice in one request is attached once. Capped at 500 items, and one audit entry is written for the batch rather than one per link.

{ "added": 37, "already": 3, "items": [ ... ] }

The case as a STIX 2.1 bundle — application/stix+json;version=2.1, downloaded as CASE-2026-001.stix.json. For a customer's TIP, a partner's MISP, or a CERT intake.

The analyst tag is the promotion path that matters operationally: a C2 domain registered this morning is in no public corpus on the day you need to tell somebody about it.

Identifiers are deterministic. Observables take a UUIDv5 over their ID-contributing properties (STIX 2.1 § 2.9), so the same file exported from two cases is one object on arrival. The report and indicators are keyed on the case reference, so re-exporting updates the receiver's copy instead of adding a report per run.

Per-item notes are not exported. The free-text "why this belongs" is internal commentary and routinely names staff, customers and working hypotheses. The report's description carries the case summary, which is written to be read.

TLP markings

If any artefact in the case arrived through one of your intel subscriptions carrying a TLP marking, the bundle gains a marking-definition object and every other object in it gets an object_marking_refs pointing at that marking. The level applied is the most restrictive any contributing indicator arrived under — mixing an AMBER indicator into a GREEN bundle downgrades the AMBER one, which is the failure worth avoiding.

{"type":"marking-definition","spec_version":"2.1",
 "id":"marking-definition--55d920b0-5e8b-4f79-9ee9-91f868d9b421",
 "name":"TLP:AMBER","created":"2022-10-01T00:00:00.000Z"}

This is what stops the export button breaching a sharing agreement. An indicator a CERT sent you as TLP:AMBER may not be passed outside your organisation; it lands in a case like anything else, and the case has a one-click export aimed at exactly the third parties the marking excludes. A case with nothing marked in it exports unmarked, as before.

Which cases already reference this artefact — the reverse lookup, and the reason it has its own index. It is what lets a file or indicator page say already part of CASE-2026-014 instead of an analyst opening a second investigation into something already being worked.

Every deadline this organisation is carrying, across every open case, worst first. Overdue stages sort above the ones still running. Optional ?within_hours=24 narrows it to a horizon — overdue stages are always included, because a deadline that has passed does not stop being the next thing to do.

Each entry carries the case (case_id, reference, title, severity) alongside the stage (framework, label, citation, due_at, hours_remaining, missing). hours_remaining goes negative once a deadline has passed rather than clamping at zero: "3 hours late" and "due now" call for different actions.

curl "http://localhost:8000/api/regulatory/due?within_hours=24" -H "x-api-key: API"

The answers recorded for this case, and every stage they imply.

Later stages chain off the previous submission, not off awareness. A NIS2 final report is one month from the notification; for an incident notified on day three, anchoring it on awareness would make it three days early, every time. DORA's initial notification carries two clocks — 4 hours from classifying it as major, 24 from awareness — and the deadline returned is whichever comes first.

missing names the fields that still block a draft, in the words the form uses. An explicitly answered false counts as answered: "no, this is not suspected to be malicious" is what the authority asked for.

The stage as a Markdown draft, downloaded as CASE-2026-014-nis2-early_warning.md. Markdown because it pastes into any authority portal's textarea and needs no rendering dependency.

409 when a mandatory field is still empty, with the list in detail.missing. A draft is refused rather than rendered with gaps — a submission reading "Impact: —" where the authority expects an assessment is worse than none: it looks complete, it goes in the file, and nobody revisits it.

Record that you filed it. Body: { "authority_reference": "CSIRT-AT-2026-1187" }.

The draft is frozen at this point. The case keeps moving; a final report filed in March must show what was said in March, not today's edited summary, or the record of what the authority was actually told is lost. The deadline is copied too, so a later correction to aware_at cannot retroactively turn a timely filing into a late one.

Two digests are frozen with it: content_sha256 identifies the document, and evidence_digest identifies the artefacts it cited. Both are readable through the evidence endpoint.

Everything about one incident, in a zip an auditor can check without trusting you. Downloads as CASE-2026-014-audit-pack.zip.

README.txt              what this proves, and what it does not
manifest.json           every file with its SHA-256, the filed digests, the chain head
case.json               the case, its regulatory answers, its timeline
evidence.md             the artefacts behind the filings, as they stand now
audit-trail.json        the audit events naming this case, and the chain's verdict
filings/nis2-notification.md    the frozen text, byte for byte

The filings are the bytes stored at submission, not re-rendered. That is the point of the pack: content_sha256 verifies against the file inside it, so an auditor can run sha256sum and compare. A pack that re-rendered would produce a document failing its own digest, which looks exactly like tampering.

The archive is reproducible — entries sorted, timestamps fixed — so two exports of an unchanged case are byte-identical and "is this the same pack you sent in March?" has an answer.

Does a filed report still rest on the evidence it was filed against? Two independent checks that answer different questions:

• content_sha256 identifies the document. Somebody holding a printout can hash it and compare, without trusting anything this platform says about it.
• evidence_digest identifies the artefacts it cited — each one's kind, reference and content hash. matches re-derives that today.

A mismatch is usually not tampering. The common cause is a retention policy removing a sample whose period ran out — legitimate, and still something a supervisor asking about the filing would want to know. So missing names the artefacts that have gone rather than only reporting that the set moved.

matches: null means the report predates these digests. "We cannot tell" and "it has changed" are different answers, and reporting the first as the second would be an accusation produced by a migration. 404 if the stage has not been filed — a draft is re-rendered from the case every time it is asked for, so there is nothing to check it against.

curl "http://localhost:8000/api/cases/14/regulatory/nis2/notification/evidence" -H "x-api-key: API"

Which outside parties this organisation receives from. Readable by any member — knowing who your platform talks to is an assurance mechanism, and hiding it from analysts only means the person who notices something odd is the one who cannot look. The stored credential is never returned, to anybody; has_secret says whether one is set.

TLP is carried through and honoured. default_tlp applies to anything the publisher sends unmarked, and defaults to amber because a collection whose onboarding email says "this is AMBER" and whose objects carry no marking is the ordinary case. Exporting a case that contains such an indicator stamps the bundle with a TLP marking-definition rather than dropping it — without that, the export button would be a way to breach a sharing agreement by accident.

Credentials are stored encrypted with the same key as mailbox passwords. TAXII uses HTTP Basic (or a bearer token when no username is set); MISP uses its API key in a bare Authorization header.

Poll immediately — the same code path the hourly scheduler runs, so a manual poll cannot succeed in a way the scheduled one would not. Returns { "status", "imported", "new", "skipped", "error" }.

It reports failure in the body rather than raising. "It failed, and here is why" is more useful to whoever configured it than a 500, and the reason is also written to the source row so a subscription that quietly stopped delivering is visible instead of inferred from a count that stopped moving.

skipped counts what could not be read. STIX patterning is a whole language; this imports simple equality on one property and refuses the rest rather than guessing — an indicator imported from the first clause of a compound pattern would match something real and wrong, which is worse than one that was never imported. A collection of four hundred compound patterns therefore reports "3 imported, 397 skipped" instead of looking like a collection with three indicators in it.

{ "sources", "enabled", "indicators", "healthy", "problems" } — one boolean a caller can act on rather than four fields each caller re-derives slightly differently.

The redirect URI to register at the provider. Its own endpoint because it is the single most common thing to get wrong, and a mismatch produces a provider-side error that says nothing useful.

This organisation's providers. The client_secret is never returned — it authenticates this platform to the customer's IdP, and a value that can be read back is one that leaks.

Add a provider. The discovery document is fetched and checked before anything is stored, so a wrong issuer is found now rather than by the first person who tries to sign in.

curl -X POST "https://api.threatera.eu/api/sso/providers" \
  -H "x-api-key: $THREATERA_KEY" -H "content-type: application/json" \
  -d '{"name":"Acme Entra ID",
       "issuer":"https://login.microsoftonline.com/<tenant>/v2.0",
       "client_id":"…","client_secret":"…",
       "email_domains":["acme.example"]}'

Update a provider. Omitting client_secret keeps the stored one — an admin editing the domain list should not have to re-enter a value they cannot read back.

Remove a provider. 204. Anyone who only ever signed in through it can no longer sign in at all: an account provisioned by the IdP has no password by construction, so invite them or re-add the provider.

Unauthenticated. Given {"email": "…"}, answers either {"sso": false} or an authorize_url — and nothing else. A chattier answer would let anybody enumerate which organisations use the product and which provider each one runs. false means "use the password form", not "that address does not exist".

The pending flow — state, nonce, PKCE verifier — is held server-side for ten minutes. Nothing about it is carried by, or forgeable from, the browser.

Where the provider sends the browser back. Redirects to the app with a session token in the URL fragment — a query string is written to every access log and proxy along the way and lands in the next request's Referer; a fragment is sent to no server at all. On failure it redirects to the sign-in screen with a readable reason.

Before any of that, the identity token must pass every check OpenID Connect asks for: signature against the provider's published JWKS, iss, aud, exp/iat, and the nonce from this specific sign-in. email_verified must be true — an IdP that lets somebody set an address without proving it would otherwise be an account-takeover primitive.

Passwords still work. Enabling SSO does not disable them. An organisation can have SSO and members who predate it, and a sign-in screen that removes the only other way in is one that locks people out on the day their IdP breaks.

A provisioned account has no password at all — not a weak one and not a random one, which could be reset into existence through the forgot-password flow. It also carries no platform MFA: the IdP performed authentication, including whatever second factor the customer's policy requires.

SAML is not implemented. Every provider worth integrating with speaks OIDC, and SAML is a second implementation with an XML signature stack behind it rather than a variation on this one. It is additive if procurement ever demands it.

Techniques in the window, grouped by tactic. days defaults to 90.

curl "https://api.threatera.eu/api/attack/coverage?days=365" \
  -H "x-api-key: $THREATERA_KEY"

This organisation's saved hunts. Each carries last_run_at, how many files that run read, the running match_count, and last_error — a rule that has stopped compiling says so here rather than quietly matching nothing.

Save a hunt. The rule is compiled before it is stored, so a syntax error is a 400 now rather than a hunt that silently never fires.

curl -X POST "https://api.threatera.eu/api/hunts" \
  -H "x-api-key: $THREATERA_KEY" -H "content-type: application/json" \
  -d '{"name":"acme-loader","enabled":true,
       "source":"rule acme_loader { strings: $a = \"acme-c2\" condition: $a }",
       "include_existing":true}'

include_existing starts the watermark at the beginning rather than at now, so the hunt's first run also walks files you already hold. Off by default — that first run is the expensive one — but without it a newly saved hunt matches nothing until fresh samples arrive, which reads as a feature that does not work.

Hunts are created disabled unless you say otherwise: a rule saved half-written should not start alerting people because the next hour came round.

Run this hunt immediately instead of waiting for the hourly job. Returns { "scanned", "matched", "error" }.

It does exactly what the scheduled run does — same watermark, same one-alert-per-file rule — so triggering it by hand cannot produce a different answer from letting it happen. It exists because a rule you have just written is one you want to see the effect of, and "come back in an hour" is how somebody concludes the feature is broken.

A rule that no longer compiles returns 400 with YARA's own message, naming the line and the token.

What this hunt has caught, newest first — the file's SHA-256, which of the rule's names matched, and when.

A file is reported once per hunt, ever. A re-run over an overlapping window, a job retried after a crash, or the same bytes submitted again by another user cannot produce a second alert.

Edit the name, the rule or the enabled flag. Editing does not rewind the watermark — re-reading everything the previous version already passed over is expensive and would re-alert on files it already reported. Delete and recreate to start clean.

Removes the hunt and its match history.

The current policy, every category with its own bounds and explanation, and pending — how many items each period would remove if the job ran now. A number of days means nothing until it is “and that is 4,182 files”.

Set the periods. Send null for a category to keep it indefinitely; 0 is rejected rather than guessed at, because it is equally readable as “forever” and as “delete everything”.

curl -X PUT "https://api.threatera.eu/api/retention" \
  -H "x-api-key: $THREATERA_KEY" -H "content-type: application/json" \
  -d '{"files_days":180,"emails_days":90,"audit_days":730}'

One month, defaulting to the current one. Pass ?month=2026-07 for a closed month. The end of the range is capped at today, so a month in progress reports the days that have actually happened.

curl "https://api.threatera.eu/api/usage?month=2026-07" \
  -H "x-api-key: $THREATERA_KEY"

Every sink configured for this organisation, each carrying the result of its last delivery — last_status, last_error, failure_count. That is the answer to "is my SIEM actually getting these", which is otherwise indistinguishable from silence. failure_count resets on success, so it says is this broken now rather than has this ever broken.

The webhook signing secret is never returned here. It is shown once, at creation, for the same reason an API key is.

The events a sink may subscribe to. Deliberately a short, closed list — forwarding everything the platform does produces a firehose nobody subscribes to.

Add a sink. events may be omitted or empty, which means every event — what wiring up a SIEM usually means, and the alternative is ticking every box today and silently missing each event type added later.

curl -X POST "https://api.threatera.eu/api/event-sinks" \
  -H "x-api-key: $THREATERA_KEY" -H "content-type: application/json" \
  -d '{"kind":"webhook","name":"SOAR","url":"https://soar.example.com/hooks/threatera"}'

{ "id": 3, "kind": "webhook", "secret": "kQ8…", "events": [] }

curl -X POST "https://api.threatera.eu/api/event-sinks" \
  -H "x-api-key: $THREATERA_KEY" -H "content-type: application/json" \
  -d '{"kind":"syslog","name":"Splunk","host":"siem.internal","port":514,"protocol":"udp","format":"cef"}'

Replace a sink's configuration. The signing secret is not rotated — changing the endpoint should not silently break every receiver that already verifies it.

Remove a sink. 204.

Queue a test event now. Without this, the first confirmation a sink works is the first real alert — the worst possible moment to find a typo'd port, and one that fails silently. The result lands on the sink; re-read it a few seconds later.

A webhook body is JSON, signed with the secret from creation:

x-threatera-event: watchlist.hit
x-threatera-signature: t=1786368000,v1=9f86d081884c7d65…

Verify it as you would a Stripe signature. The timestamp is inside the signed material, not merely alongside it — signing the body alone leaves a captured request valid forever, and a replayed "case closed" is worth worrying about. Check the age first, then compare digests in constant time:

import hmac, hashlib, time

def verify(secret, body, header, tolerance=300):
    parts = dict(p.split("=", 1) for p in header.split(","))
    ts = int(parts["t"])
    if abs(time.time() - ts) > tolerance:   # reject replays first
        return False
    expected = hmac.new(secret.encode(), f"{ts}.".encode() + body,
                        hashlib.sha256).hexdigest()
    return hmac.compare_digest(expected, parts["v1"])

The body is serialised with sorted keys and no whitespace, so a receiver that re-serialises to verify can reproduce the exact bytes that were signed.

CEF. A syslog sink emits RFC 3164 lines carrying a CEF payload, using CEF dictionary names where one exists (src, fname, fileHash, msg) so a rule written against src works across products. Values are escaped for both CEF layers — including newlines, since a raw one would end the syslog line and let a crafted indicator inject a second event into your SIEM.

CEF:0|Threatera|Threatera|1.0|watchlist.hit|A watched value was seen|8|msg=Watched value seen: evil.example cs1=evil.example cs1Label=value cs2=lookalike domain cs2Label=reason

Everything your organisation is watching, noisiest first. Each rule carries hit_count, sighting_count and last_hit_at.

New rules are checked against what you already hold. Bounded to the most recent 2,000 indicators or files, and the count comes back as backfilled. Without it the first thing anyone does — test the rule against something they know they have — answers with silence, which reads as "it does not work".

Watch several values in one request — the shape a feed import produces, where fifty indicators land at once and all of them want watching.

{ "values": ["cdn-node.example.com", "203.0.113.42", "d41d8cd98f00b204e9800998ecf8427e"],
  "severity": "high",
  "label": "from the 14 Sep loader feed" }

Values, not rules. The kind of each one is inferred, because a caller selecting rows in the indicator list has it already and should not restate it per value; send kind to override for the whole batch. Anything that cannot be placed confidently is refused by name rather than guessed at — storing a rule under a kind that can never match is the silence this feature exists to avoid. severity and label apply to every rule created.

Already watched is not an error here, unlike POST /watchlist's 409. In a batch it is the ordinary case — you select fifty and six are already watched — and refusing would mean working out which six before the other forty-four can be added. The same value sent twice in one request is added once. Capped at 500 values.

The backfill is one pass, not one per rule: bounded by the number of distinct kinds of thing to read rather than by the size of the selection, so hash reads files, ip reads IP indicators, and domain and email share the domain scan — three at the very most. Fifty bounded scans inside one POST is the timeout the bound was there to prevent.

{ "added": 44, "already": 5, "backfilled": 11,
  "rejected": [ { "value": "http://example.com/gate.php",
                  "reason": "only domain, ip, hash, email can be watched — …" } ] }

What the watchlist has seen, most recent first. Params: acknowledged (omit for everything, false for the open alerts), rule_id, severity, sort, limit, offset. Returns { "total": n, "results": [...] }.

sort is field:asc or field:desc over last_seen, first_seen, value, times, why (the rule's label), source_kind or severity — ranked, for the same reason as cases.

Each hit carries the value that actually matched — for a suffix or CIDR rule that is not the pattern, and 10.0.0.0/8 matched is not something anyone can act on — plus the rule's rule_label and severity, and an href into the UI.

Your own TAXII/MISP subscriptions are swept by the same pass, and land in the same list with source_ref prefixed intel:. A CERT naming an address you watch is the same event as abuse.ch doing so — arguably a more urgent one, since it was sent to you specifically — and putting it in a second place to check is how it gets checked less. Only domain and ip are swept: a hash rule is matched at ingest, and no sweep can tell you a hash became bad.

Repeats bump rather than duplicate. The same (rule, source, value) updates last_seen and increments times. Re-analysing one archive full of watched domains produces one alert per value, not forty — which is the difference between a list people read and a list people mute.

Mark a hit as dealt with. Body: { "acknowledged": true }, or false to put it back — reversible on purpose. An alert cleared in a hurry and recognised an hour later as the start of something is ordinary, and a one-way control makes people hesitate before clearing anything, which is how a list stops being read at all.

Acknowledge — or reopen — several alerts at once. Clearing forty was forty round trips, which is the shape of work this list produces: a noisy rule fires on one afternoon's traffic and every hit needs the same answer.

Body: { "ids": [1, 2, 3], "acknowledged": true }. Capped at 500 ids.

{ "acknowledged": 37, "unchanged": 1, "missing": [41, 42] }

It reports what it did. acknowledged counts the rows actually changed, unchanged those already in that state (a repeat request is safe and says so), and missing names ids that were not your organisation's to touch.

{ "open_hits": n, "active_rules": n } — what the badge in the navigation shows. Cheap enough to call on every page load: it is answered by a partial index over unacknowledged hits only.

Mail. A tenant owner can set an alert address under Tenant settings (PATCH /api/tenants/{id}, field alert_email). A daily job then sends one digest per organisation of the hits nobody has acknowledged. It is NULL by default, so an installation with a mail server configured still sends nothing to anyone who did not ask; and it is one address per organisation rather than one per user, because an alert belongs to a team list that outlives whoever wrote the rule.

Reported messages, newest first. Params: verdict, q (matches subject, sender or Reply-To), sort, limit, offset. Returns { "total": n, "results": [...] }.

sort is field:asc or field:desc over received_at, sent_at, subject, from_address or verdict — ranked, worst first: as plain text clean sorts before malicious, which is the exact inverse of what somebody working a phishing queue is looking for.

Each row also carries analyst_verdict, analyst_note, decided_by and decided_at — what a person concluded, beside the derived verdict. Null means nobody has looked. Written by PUT /email/messages/verdict.

One message with everything the analysis produced:

Record the same conclusion about several reported messages at once. Body: { "ids": [...], "verdict", "note" }, where verdict is one of confirmed, false_positive, benign, needs_work — or null to withdraw the decision and return the messages to “nobody has looked”.

A reporting mailbox produces the most repetitive queue in the product: forty people forward one campaign inside an hour and every one of them gets the same answer. The note is therefore checked once against the batch — a reason good enough for forty messages is a reason, and asking forty times is how somebody types “fp” forty times. It is required to clear something the headers called malicious or suspicious, exactly as PUT /files/verdict requires it.

Reports what it did rather than that it succeeded: decided counts the rows written and missing names the ids that were not yours to touch. Capped at 500 ids.

{ "decided": 37, "missing": [418, 419, 420] }

Analyse a .eml directly — multipart/form-data with a file part, no mailbox involved. Returns the same shape as the detail endpoint above.

409 if this organisation has already analysed a message with the same Message-ID. Available whether or not mailbox polling is enabled: the switch governs automatic collection, not a file an analyst chose to submit.

This organisation's reporting mailbox, plus ingest_enabled — the installation-wide switch, so a client can distinguish "configured" from "configured and never polled".

Polling is a scheduled job (k8s/mailbox-poll-cronjob.yaml, every 15 minutes), not a request you make. Messages are marked \Seen and left in the mailbox; nothing is deleted and no reply is ever sent.

Turn several detection rules on or off in one request, across all three engines — pushing a set live, or silencing a family that has started firing on everything. Each rule is named by its engine and the same reference its own route takes:

{ "rules": [ { "engine": "yara",  "ref": "YARAForge:APT28_Downloader" },
             { "engine": "sigma", "ref": "susp_office_macro_autoopen" },
             { "engine": "hunt",  "ref": "14" } ],
  "enabled": false }

engine is yara, sigma or hunt; anything else is a 400. ref is the rule name for yara and sigma and the id for a hunt. Capped at 500 rules.

Already in the requested state is not counted as a change, so a repeated request is safe and says so. missing names references that were not yours to touch — a rule belonging to another customer and one that does not exist are the same non-match under row-level security.

{ "changed": 2, "muted": 31, "unchanged": 1, "missing": ["yara:no_such_rule"] }

List all rules (without source). Each carries name, enabled, created_at, platform and source_feed. Related operations:

Your rules and the installation's

platform: true marks a rule this installation provides — the two examples a fresh install ships, and everything imported from a rule feed (source_feed names which). One row is shared by every organisation and belongs to none of them.

Scan already-stored files with a YARA rule and return the matches. Validates the rule compiles, then scans up to limit (max 1000) of the most recently ingested files.

curl -X POST https://api.threatera.eu/api/retrohunt \
  -H "x-api-key: $THREATERA_KEY" -H "content-type: application/json" \
  -d '{"source":"rule x { strings: $a = \"evil\" condition: $a }","limit":500}'

List all rules with their source, enabled state, and the title / level parsed out of the rule itself. Related operations:

Rules also carry platform and source_feed, and the platform-rule rules are identical to YARA's — see there for why a shared rule is muted rather than disabled, and why enabled reports what is in force for you rather than the stored column.

curl -X POST https://api.threatera.eu/api/sigma-rules \
  -H "x-api-key: $THREATERA_KEY" -H "content-type: application/json" \
  -d '{"name":"beacon_over_tls","source":"title: Sample beaconed over TLS\nlevel: high\nlogsource:\n  category: network_connection\ndetection:\n  sel:\n    DestinationPort: 443\n  condition: sel"}'

The comment thread on one artefact, newest first. Optional limit (1–500, default 100).

Comments are addressed by value, not by foreign key — you can annotate something that hasn't been ingested yet, and the thread survives re-ingestion. 400 if the target type or value is malformed.

Add a comment. Body: { "body": "…" } — non-empty after trimming, at most 4000 characters (422 otherwise). Returns 201 with the stored comment.

curl -X POST https://api.threatera.eu/api/comments/ioc/evil-c2.com \
  -H "x-api-key: $THREATERA_KEY" -H "content-type: application/json" \
  -d '{"body":"Seen in the Acme phishing wave, 2026-07-19."}'

{
  "id": 7, "target_type": "ioc", "target_value": "evil-c2.com",
  "author": "alice", "body": "Seen in the Acme phishing wave, 2026-07-19.",
  "created_at": "2026-07-28T09:14:52Z"
}

Delete a comment. Allowed for its author or an admin; 403 for anyone else, 404 if it doesn't exist. Returns 204.

There is no voting or reputation scoring — that needs a trust model this deployment doesn't have.

What needs attention, then what the volumes look like. The two lists it leads with are open cases and unacknowledged watchlist hits — the question somebody opening a dashboard actually has. Totals and breakdowns follow.

{
  "totals": {"files":24,"iocs":281,"urlscans":31,"detonations":93,
              "yara_rules":4,"sigma_rules":11,"open_cases":3,"open_alerts":7},
  "open_cases": [{"id":14,"reference":"CASE-2026-014","title":"…",
                  "severity":"high","status":"open", … }],
  "open_alerts": [{"id":88,"value":"login.acme-sso.com","source_kind":"urlscan",
                   "severity":"high","why":"our domains","last_seen":"…"}],
  "verdicts": {"clean":19,"malicious":3,"suspicious":2,"unknown":2},
  "ioc_types": {"domain":244,"ip":36},
  "new_files_daily": [{"date":"2026-07-20","count":3}],
  "new_email_daily": [{"date":"2026-07-20","count":1}],
  "top_iocs": [ … ],
  "regulatory": {"available":true,
                  "summary":{"open":2,"overdue":1,"hours_to_next":-3.2,
                              "cases":2,"unanchored":1},
                  "stages":[{"case_id":14,"reference":"CASE-2026-014",
                             "framework":"nis2","label":"Early warning",
                             "hours_remaining":-3.2, … }]},
  "search_available": true
}

open_cases and open_alerts appear twice on purpose: as a count in totals, and as the first few rows. The lists are capped at six each — the totals are not, so a badge and a list can disagree about length without either being wrong. A case row also carries assignee, updated_at and item_count.

Cases are ordered by severity explicitly, not as a string: alphabetically critical sorts before low, so a naive sort looks right and is wrong at exactly the moment it matters. monitoring counts as open — actions taken, watching for recurrence, still somebody's work.

new_email_daily is bucketed on when the platform received the report, not on the message's own Date: header — a forwarded report of a March mail would otherwise land in March and never appear in a 14-day chart, and a header date is attacker-controlled anyway. Both daily series fill gaps with zero, so a client can plot them without reindexing.

Lightweight overview counts: { "files", "iocs", "analyses", "yara_rules", "sigma_rules" }. Every one of them is counted from the per-organisation tables, never the global ones — a count taken from the shared corpus would report every other customer's volume to you.

The nodes and edges around a file or an indicator, for a relationship view. Walks the links the platform already holds: indicators extracted from files, indicators contacted by URL scans, and observed domain → IP resolutions.

Query parameters

{
  "nodes": [
    {"id":"file:8d0a…a255",   "type":"file",    "label":"8d0aa1b2c3d4…", "hash":"8d0a…a255"},
    {"id":"domain:evil-c2.com","type":"domain",  "label":"evil-c2.com",   "value":"evil-c2.com"},
    {"id":"ip:93.184.216.34",  "type":"ip",      "label":"93.184.216.34", "value":"93.184.216.34"}
  ],
  "edges": [
    {"source":"file:8d0a…a255",   "target":"domain:evil-c2.com", "kind":"extracted"},
    {"source":"domain:evil-c2.com","target":"ip:93.184.216.34",  "kind":"resolved"}
  ]
}

Node ids are type-prefixed (file:, domain:, ip:, urlscan:) so a domain and a file can never collide; label is the display form (file labels are the truncated hash). Edge kind is one of:

Edges are undirected for drawing purposes and de-duplicated, so expanding a domain and then its IP won't emit the same resolution twice. 404 if the seed matches nothing.

The public threat feeds this installation ingests — how many indicators each holds, when it last synced, and whether it is stale.

Readable by any authenticated user. A feed match is what the platform asserts about an indicator, so an analyst weighing that assertion needs to know which sources back it and how current they are. Nothing here is tenant-specific: the corpus is identical for every organisation.

{
  "enabled": true, "stale_after_hours": 48,
  "healthy": false,
  "problems": [{"feed":"urlhaus","health":"stale",
                "detail":"stale","stale_since":"2026-08-03T19:42:32Z"}],
  "feeds": [{"key":"urlhaus","name":"URLhaus","health":"stale","stale":true,
             "indicators":412031,"last_sync":"…","status":"ok","error":null,
             "licence":"CC0","homepage":"https://urlhaus.abuse.ch/"}]
}

healthy is one boolean a caller can act on rather than four fields each caller re-derives slightly differently: false whenever the subsystem is off, holds no feeds, or any feed is not answering for itself. problems is the same set, spelled out. Per feed, status is what the last sync run reported and health is the judgement about the feed now — a run that finished cleanly two weeks ago is status: "ok" and health: "stale", and the second one is the one to act on.

Matches appear on the indicator itself, under enrichment.feeds in GET /api/iocs/{value} — each entry naming the feed, what it calls the threat, a confidence where the source publishes one, and a link back to the source's own page.

Ingestion is inbound only: the platform downloads the same files every other subscriber gets, on a schedule unrelated to anything you submitted. Nothing about your samples leaves. That is why this is on by default while per-lookup enrichment such as RDAP is not — a lookup query would reveal what you are investigating.

Sources: URLhaus, ThreatFox and Feodo Tracker (abuse.ch, CC0) and the Tor Project's exit list.

Curated detection rulesets this installation imports — how many rules each holds, when it was last refreshed, and whether it is stale. A fresh install ships two example YARA rules; the import adds roughly five thousand.

Readable by any authenticated user, for the same reason /api/feeds is: this is what the platform asserts it can detect, and an analyst reading a clean verdict deserves to know whether the ruleset behind it was refreshed on Tuesday or never.

Each package is imported as one platform-provided rule rather than one rule per detection: the file carries import "pe" / "dotnet" / "hash" and a few rules whose condition references another by name, and splitting it breaks both.

Source: YARA-Forge core package (community YARA rules, deduplicated and licence-filtered upstream). There is deliberately no Sigma feed — of SigmaHQ's 1,377 core rules, 0 use only the event fields this Linux sandbox produces, so importing it would show coverage that cannot fire.

Server-side limits a client should respect before uploading: { "max_upload_size_mb": 100 }.

Read this rather than hard-coding a number — it lets you reject an oversized file instantly instead of streaming it only to be 413'd, and it makes the effective limit visible when debugging a deployment whose config differs from the default.

Active platform announcements (maintenance windows, notices), newest first — visible to every authenticated user.

Per-dependency status and resource usage. Probes Postgres, Elasticsearch, Redis, MinIO, ClamAV and the detonator concurrently, so the response takes as long as the slowest single probe rather than their sum.

Platform operators only. Nothing here is one organisation's data, but all of it is the installation's — which services exist, which are failing and with what error — which makes it an inventory of the platform to anyone renting it rather than running it.

{
  "status": "degraded",
  "degraded": ["clamav"],
  "services": [
    {"service":"postgres","status":"up",  "latency_ms":2.1,    "version":"16.4"},
    {"service":"clamav",  "status":"down","latency_ms":5002.0, "error":"probe timed out after 5s"}
  ]
}

status is ok only when every dependency is up, otherwise degraded with the failing ones listed. A dependency that is down is reported, never raised — the whole point is to see which one broke, so a single failure can't take the response down with it.

Each entry always carries service, status and latency_ms. error appears only on failure, and healthy probes add their own detail fields (versions, signature counts, disk usage), so treat the extra keys as per-service rather than fixed.

Operator only. Whether the scheduled work actually ran, and whether anyone is consuming the task queues — a different question from the one above, and the one that has twice been answered wrongly by a page full of green.