Flagged by whom, and does it actually mean this host
The Threat Intelligence API returns URL, domain and IP reputation as clean JSON.
5 active endpoints. Every call is 1 credit.
- POST/threat-intel/v1/url_check
- POST/threat-intel/v1/domain_reputation
- POST/threat-intel/v1/ip_reputation
- POST/threat-intel/v1/scan_lookup
- POST/threat-intel/v1/batch
What Threat Intelligence endpoints does ReefAPI ship?
5 live read endpoints. Read-only data API: no writes, no account actions, no dashboard access on the target site.
Threat Intelligence API
3 of 5 endpoints, ready to run
A verdict and score for one URL with each contributing source listed, whether the match was on the host or the exact path, and whether the host is multi-tenant.
{ "ok": true, "meta": { "api": "threat-intel", "endpoint": "url_check", "mode": "live", "latency_ms": 694.1, "record_count": 2, "cache_hit": false }, "data": { "target": "https://github.com", "type": "url", "malicious": false, "verdict": "suspicious", "score": 70, "dedicated_signals": 1, "shared_hosting": true, "sources": [ { "source": "urlhaus", "type": "hosts_flagged_content", "match": "host", "shared_hosting": true, "dedicated": false, "weight": 0, "malware_urls": 36, "active_malware_urls": 11, "in_hostfile": false, "note": "this is a multi-tenant host; the flagged content lives at specific paths — the domain itself is not condemned", "sample": "https://github.com/bbaltaci90/file/raw/refs/heads/main/naHOjMlaWC163.bin" }, { "source": "threatfox", "type": "domain_ioc", "match": "domain", "dedicated": true, "weight": 70, "ioc_count": 1, "threat_type": "payload_delivery", "malware": "ClearFake", "confidence_level": 100, "first_seen": "2026-08-27 17:25:50" } ], "threat_types": [ "malware_download", "payload_delivery" ], "malware": [ "ClearFake" ], "flags": [], "checked_sources": [ "urlhaus", "openphish", "threatfox" ] } }
How the Threat Intelligence API works
Threat Intelligence is a normal ReefAPI surface — the same four rules that hold for every other engine on the key.
No OAuth app, no request signing, no per-site account. One key covers all 184 engines.
Every route is a POST with a JSON body. Parameters are validated against the published schema before anything is charged.
Credits, not seats. Failed and blocked calls are never charged, and cache hits cost nothing.
One envelope everywhere. meta carries latency_ms, record_count and the endpoint that answered.
Screening a link a user pasted, without blocking half the internet
Naive reputation checks block anything on a host that has ever served something bad. That bans every file-sharing service, every code host and most of the CDNs.
{"url": "https://example.com/some/path"}Returns the verdict plus, for each matching source, whether the match was on the host or the exact URL, and whether the host is shared.
A dedicated signal means the flag is about this host. A host match on a multi-tenant platform means somebody's uploaded file, not the platform.
The distinction is in the payload rather than left to you: one of our test URLs was a major code-hosting domain, and the response said in as many words that the flagged content lives at specific paths and the domain itself is not condemned.
curl -X POST https://api.reefapi.com/threat-intel/v1/url_check \
-H "x-api-key: $REEF_KEY" \
-H "content-type: application/json" \
-d '{"url":"https://github.com/"}'{
"ok": true,
"data": { … },
"meta": {
"api": "threat-intel",
"endpoint": "url_check",
"mode": "live",
"latency_ms": …,
"record_count": …
},
"error": null
}What each indicator type is actually checked against
The verdict is an aggregation of open block-list feeds, and which feeds run depends on what you passed. Every response echoes checked_sources so you can see exactly which lists were consulted for that indicator, and sources holds one block per feed that matched, each with its own weight. A feed with weight 0 is informational and does not move the verdict.
| Action and input | Feeds in checked_sources | Fields you only get here |
|---|---|---|
| url_check, a full http or https URL | urlhaus, openphish, threatfox, feodo, sslbl, spamhaus_drop, heuristics | flags[] from the heuristics pass, for example non_https and ip_literal_host |
| domain_reputation, a bare host | urlhaus, openphish, threatfox, urlscan, heuristics | malware_urls[] with status online or offline and dateadded, plus urlscan_scans |
| ip_reputation, IPv4 or IPv6 | feodo, sslbl, threatfox, urlhaus, spamhaus_drop | c2_ports[], and per-source as_name, country, first_seen and last_online |
| scan_lookup, a domain or IP | urlscan.io public search only | scans[] with uuid, server, country, tls_age_days and a per-scan malicious flag |
| batch, up to 20 mixed indicators | auto-routed per detected type | each result echoes your original string as input, plus malicious_count and ok_count |
Measured score points: 0 with no hits at all, 10 for heuristic flags alone (http://1.2.3.4/x.exe scored 10 on non_https plus ip_literal_host and the verdict stayed clean), and 80 for a single Feodo botnet-C2 hit, which flipped the verdict to malicious. dedicated_signals counts the sources that condemn the indicator itself, and it is the field to branch on rather than the raw score.
What the verdict is built from
Measured on a clean major brand and on a large multi-tenant host. The second row is the one that decides whether this is usable in production.
A clean domain came back with an empty source list and an explicit list of the feeds that were checked. 'Nothing found' and 'we did not look' are different claims, and the response distinguishes them without you having to ask.
Every matching source reports whether the hit was on the host or on the specific URL, whether the host is multi-tenant, and how many flagged URLs exist under it. A big code host scored suspicious on host matches while the payload stated plainly that the domain itself is not condemned. Collapsing that into one boolean is how naive filters end up blocking GitHub.
Alongside the verdict you get the numeric score, the count of dedicated signals, the threat types and the malware families named by the feeds. If your risk appetite differs from ours, the inputs are there to apply your own threshold rather than accepting our label.
Where a feed flagged specific URLs under a host, a sample is returned along with the count of active ones. An analyst can see what the feed is actually complaining about instead of taking the flag on trust.
A clean verdict means the public feeds we consult have nothing on this target today. Fresh phishing infrastructure is routinely hours ahead of any feed, so a clean result is a reason not to raise an alert, not a reason to trust a link. The score is built to be combined with domain age and impersonation signals, not used alone.
What people build with Threat Intelligence
The jobs this data is most often used for.
endpoints
credit per call
Anti-abuse systems call url_check to block malicious links in user-generated content in real time.
Trust-and-safety teams use ip_reputation to score traffic and flag known-bad addresses.
Security tools use batch to screen a list of domains against multiple threat feeds at once.
What Threat Intelligence data costs
The cheapest call here is 1 credit, so $15/mo (Pro) buys 10,000 of them — $1.50 per 1,000 credits. Credits roll over and never expire, and failed or blocked calls are not charged.
Full pricing →- 1,000 free credits on signup, no card
- One key, all 184 APIs, one credit pool
- Failed and blocked calls are never charged
- Credits roll over and never expire
Call it in two lines
Sign up, get 1,000 credits and one key that works on every engine. Then this is the whole protocol.
curl -X POST https://api.reefapi.com/threat-intel/v1/url_check \
-H "x-api-key: $REEF_KEY" \
-H "content-type: application/json" \
-d '{"url":"https://github.com/"}'import requests
r = requests.post(
"https://api.reefapi.com/threat-intel/v1/url_check",
headers={"x-api-key": REEF_KEY},
json={
"url": "https://github.com/"
},
)
print(r.json()["data"])Have a question? We got answers.
The questions people actually ask before wiring up Threat Intelligence.
Get a free key →github.com is hosting live malware URLs, so why is the verdict clean?▾
Because the domain is multi-tenant and the flagged content lives at specific paths. A measured domain_reputation on github.com returned verdict clean, score 0 and dedicated_signals 0, while sources[0] reported malware_urls 48, active_malware_urls 21, shared_hosting true, dedicated false, weight 0 and an explicit note that the domain itself is not condemned. threat_types still listed malware_download and malware_urls carried the 48 URLs with their dateadded timestamps. For a host like this, check the exact URL with url_check rather than the domain.
Can score be non-zero while the verdict is clean?▾
Yes, and that is the normal case for heuristics. The spec's own example URL, an http link with a bare IPv4 host, returned score 10 with flags ["non_https", "ip_literal_host"], an empty sources array, dedicated_signals 0 and verdict clean. Heuristic flags add points because the shape of the URL is suspicious, but no feed reported it. If you gate on score alone you will block ordinary internal HTTP links.
Is a clean verdict authoritative?▾
No. These are reported-abuse feeds, so clean means nothing is currently listed rather than nothing is wrong. A measured ip_reputation for 8.8.8.8 returned record_count 0, an empty sources array and verdict clean after checking five feeds. Read checked_sources to confirm which lists ran, and pair this with domain-risk when you need a judgment on a domain that is too new to have been reported yet.
The verdict is malicious but the source says status offline. Which is it?▾
Both. A measured ip_reputation on 162.243.103.246 returned verdict malicious with score 80 from a single Feodo block: malware Emotet, port 8080, as_name DIGITALOCEAN-ASN, country US, first_seen 2022-06-04 and last_online 2026-03-07, with status offline. Feodo keeps historical command-and-control records, so read last_online before treating the address as live infrastructure, and c2_ports if you are writing firewall rules.
What does meta.record_count count here?▾
Matching source blocks, not indicators. A clean IP returned 0, the github.com URL returned 1 because one informational URLHaus block matched, and a four-target batch returned 4 because batch counts inputs instead. Never read record_count as a threat count; use dedicated_signals for that, or malicious_count on batch.
scan_lookup returned ok true with an empty scans array. Was the domain never scanned?▾
Not necessarily. urlscan.io's anonymous search is aggressively rate-limited, and a measured github.com lookup returned ok true with stop_reason source_unavailable, total 0, an empty scans array, urlscan_available false and urlscan_status "urlscan rate-limited/blocked (HTTP 429)", plus a note suggesting domain_reputation instead. Branch on urlscan_available rather than on the length of scans, or you will record an unavailable source as a clean history.
How is this different from domain-risk?▾
threat-intel answers whether anybody has reported this indicator, by consulting block-lists. domain-risk answers whether a domain looks like a fraud setup, from RDAP age, expiry, nameservers, mail records, certificate transparency and lookalike structure, with no block-list involved. A phishing domain registered this morning is typically clean in threat-intel and elevated in domain-risk, so run both when you are scoring an unknown host.
How does batch decide which feeds to run for each entry?▾
It detects the type of each string and routes it. A measured batch of a URL, a domain, an IP and an IP-literal URL returned four results with different checked_sources arrays, an ok flag and an input echo on each, plus top-level malicious_count 1 and ok_count 4. The cap is 20 indicators per call, and a mixed batch of clean targets came back in about two seconds because the feed snapshots are shared across the entries.
What is the Threat Intelligence API?▾
Threat Intelligence API is a ReefAPI endpoint group for threat intelligence It returns live JSON through POST requests under /threat-intel/v1.
Is the Threat Intelligence API free to try?▾
Yes. ReefAPI starts with 1,000 free credits, no card required. Threat Intelligence calls use the same shared credit balance as every other ReefAPI engine.
Do I need a Threat Intelligence login or account?▾
No login to Threat Intelligence is needed for the API response. You call ReefAPI with your x-api-key header, and the playground can run live examples before you create a production key.
How fresh is the Threat Intelligence data?▾
The page example is captured from a live url_check call, and production requests fetch live data through ReefAPI rather than a static sample.
How many credits does the Threat Intelligence API use?▾
Threat Intelligence actions currently cost 1 credit per successful call. Failed or blocked calls are free, and all APIs draw from one credit pool.
Can I call Threat Intelligence from an AI assistant or MCP client?▾
Yes. Connect ReefAPI once through MCP and your assistant can call threat-intel actions with the same key, credit pool and JSON envelope used by normal REST requests.
18 Developer Tools APIs on the same key
One key, one credit pool, one response envelope. If you are pulling Threat Intelligence, you are one call away from the rest of the category — no second contract, no second integration.
Need something this API does not do?
Name the endpoint, the field, or a source we do not carry yet. We ship new APIs every week and you would be first to get the key. Real people read every message and reply the same day.
Try it on your own data before you pay anything
The call above is the real endpoint, not a recording. A free key gives you 1,000 credits, the other 183 APIs, and the same envelope everywhere.
Endpoints, parameters and credit costs on this page are read from the live catalog and cannot drift from what the API accepts. Field notes were captured on 2026-08-30.