Documentation de l'API

Liveness probe for load balancers and monitoring. Returns a small JSON payload when the API process is up.

Machine-readable API description (may lag slightly behind this page; routes are defined in apps/rust-api).

High-level counts and trends from cached metrics (threat overview, categories, recent activity).

Reads sub-documents from the metrics:threats Redis JSON. Optional metric query selects one slice (same names as the Next.js /api/analytics route).

EPSS bucket distribution, top CVEs, and summary counts from CveCatalog. Query params filter results.

Time-bucketed counts by severity, KEV, and active exploit flags from CveCatalog.lastModifiedAt.

Comprehensive threat intelligence check. Supply one target via query or legacy aliases ip, domain, or hash (same semantics as query). Supports IPv4/IPv6, domain, URL, or file hash (MD5/SHA1/SHA256 hex). Response size depends on enrichment: basic, standard (default), or full. If no target is provided, the API still returns 200 with a minimal body (malicious: false, apiVersion, enrichmentLevel) — prefer validating client-side. For smaller, stable JSON use sub-endpoints (/check/reputation, etc.). Verdict semantics: malicious reflects high-confidence scanner-style signals (Google Safe Browsing, ransomware IOC matches), while blocklistHits / blocklistListed count the feed listings that are threat opinions — every entry of sources[] carries the registry threatClass (threat, the default; infrastructure; policy; allowlist) and fpRisk (low, medium, high), and only threat-class listings that are not ad/tracker-only lists are counted or weighed. Infrastructure: when at least one listing describes what the indicator *is* rather than what it did (Tor exit, VPN egress, cloud/CDN range, DoH resolver, crawler, sinkhole, URL shortener…), the response adds an infrastructure block: attributes (distinct, sorted, e.g. tor-exit, cloud, doh-resolver) and the sources behind them. Those listings never raise malicious, the risk score or the blocklist counters, and the key is absent when no such listing exists. File hashes: a hash no source has seen answers lookupStatus: "unknown" (known otherwise) with riskScore.level inconclusive — absence of evidence, never a clean verdict, so do not release a file on it. The miss is cached for five minutes: ask again after that rather than caching unknown on your side. A 40-hex (SHA-1) or 32-hex (NTLM, same shape as MD5) value that is the hash of a breached password adds pwnedPassword (hashType, count, corpusUpdatedAt, from Have I Been Pwned's Pwned Passwords); it never changes malicious, the risk score or lookupStatus, and is absent otherwise. Data Trust: responses include dataTrust for freshness, source reliability, completeness, and provider agreement, plus evidence for SOC-ready reasons, contradictory signals, and recommendedAction. OTX: With standard or full enrichment, the response may include otx — normalized AlienVault OTX data: community pulses (and optional reputationScore from indicator general). For IPs, full adds LevelBlue Labs labsReputation and a capped passive DNS summary. For domains, full adds passive DNS. For URLs (primary query is http(s)://...), OTX uses the URL indicator. For file hashes, standard/full may include pulse context from file/.../general; full may add a capped fileAnalysis excerpt. Uses the public OTX API; optional OTX_API_KEY improves rate limits. Omitted on basic or when OTX fails. Reports history: checks are not saved automatically — to keep a report, call POST /reports/save (platform API, session or API key) with the check result.

Get reputation data aggregated from the threat-intelligence feed corpus.

Get geographic location data including country, city, region, ISP, and coordinates.

Get WHOIS registration data including registrant, registrar, and dates.

Get SSL/TLS certificate information including issuer, validity, and chain.

Get known vulnerabilities associated with an IP address from CVE databases.

Proxies an observable to IntelOwl (/api/analyze_observable) when INTELOWL_URL and INTELOWL_API_KEY are configured. Results are cached in Redis (~1h). Use HEAD to probe without body. Set cache_only=true to return only cached data (404 if missing).

Same route as GET; use HEAD for connectivity checks without a response body.

Without query, or with type=stats, returns aggregated ransomware stats from cache (ransomware:stats) or computed from recent victims. With query, returns a lightweight stub for entity-oriented checks (full deep-dive uses dashboard / GET /ransomware/* routes). Optional include_ttps, include_iocs, limit are parsed for forward compatibility.

Returns azureTenant data from Redis for a domain (not supported for raw IPs).

On api.ismalicious.com this route scores an email from the signals the threat-intel backend owns directly: blocklist listings of the address itself (email feeds), the domain's threat level and disposable status from the corpus, and live DNS posture (MX, SPF, DMARC, DKIM). The score is a weighted computation with per-factor breakdown — same score bands as the full analysis.

For extended email risk analysis (breach catalog, EmailRep reputation, typosquatting patterns), call the Next.js route on the main site with the same auth pattern your app uses for dashboard API calls:

GET https://ismalicious.com/api/check/email?email=user@example.com

(Implementation: apps/web/app/api/check/email/route.ts.)

On ismalicious.com this route auto-detects crypto, email, phone, hash, URL, IP, or domain and forwards to the matching check handler.

POST https://ismalicious.com/api/analyze

Host split: not available on api.ismalicious.com (Rust). SDK clients must set webBaseUrl: 'https://ismalicious.com/api' (default in SDK) for analyze / checkEmail / checkPhone / checkCrypto; keep baseUrl for /check and other Rust routes.

Body: { "input": "..." } (optional input_type / query aliases). Auth uses the same API key or session pattern as other web API routes.

(Implementation: apps/web/app/api/analyze/route.ts.)

Phone risk analysis on the web app (heuristics + optional IPQS when configured).

GET https://ismalicious.com/api/check/phone?phone=%2B14155552671

(Implementation: apps/web/app/api/check/phone/route.ts.)

Checks BTC/ETH wallet addresses against ingested ScamSniffer and related scam indexes.

GET https://ismalicious.com/api/check/crypto?address=0x...

(Implementation: apps/web/app/api/check/crypto/route.ts.)

Whether the password behind a SHA-1 or NTLM hash appears in Have I Been Pwned's Pwned Passwords corpus (over 2 billion hashes per form, held on our servers and refreshed monthly), how many times, and a prevalence level: rare (1–9 sightings), common (10–999), very_common (1,000+).

Send exactly one of sha1, ntlm or hash (40 hex reads as SHA-1, 32 as NTLM). Never send the password itself: a password field is refused with 400. Nothing is cached, stored or saved as a report. For k-anonymity, where only 5 hex digits leave your side, use GET /pwned-passwords/range/{prefix} below — the JavaScript SDK's checkPassword() does that for you.

not_found means the password is not in known breach dumps; it says nothing about its strength. One request of the monthly quota; 503 until the corpus is loaded.

Every hash of Have I Been Pwned's Pwned Passwords corpus under a 5-hex prefix, with its breach count. Hash the password yourself (SHA-1, or NTLM with mode=ntlm), send the first 5 hex digits, and compare digits 6–17 of your hash with entries[].suffix: neither the password nor its full hash leaves your side. Answered from a local copy of the corpus, refreshed monthly.

Anonymous callers get 10 requests per hour and 50 per month per IP (the Free key's quota); an API key pays one request of its monthly quota. 503 until the corpus is loaded.

Returns plan label, maxEntitiesPerRequest for your subscription, and allPlans limits map. The JSON may include endpoint as /api/bulk/check (legacy string); the real URL is https://api.ismalicious.com/bulk/check. POST the same path with a JSON body to run a batch.

Request body: entities (required array of strings), optional enrichment, optional format (json default, or csv for a CSV body). Per-request entity caps by plan: FREE 10, BASIC 50, PRO 100, ENTERPRISE 500. Each result includes the same SOC evidence summary fields used by single checks: evidence, recommendedAction, analystStatus, and observedAt. confidence is 0–100. Hash rows add lookupStatus (known | unknown): an unknown hash omits riskScore, riskLevel and confidence — there is no evidence either way, which is not a clean verdict.

Scans one inbound message. Charges one scan of the scan meter (not a request). 400 when none or several of emlBase64, eml and message are sent, or the input is not an email; 413 over 10 MiB; 429 over the scan allowance (refused before the message is read, and not charged); 503 with Retry-After when the scan is busy. Also served at https://ismalicious.com/api/mail/scan.

Three modes on one path. With id, the canonical single-CVE lookup: one record with CVSS, EPSS, CISA KEV status and due date, exploitation evidence and references[] (GET /cve/{id} is an alias; /check/cve, /vulnerability/{id} and /vulnerabilities/{id} do not exist). With query, a case-insensitive search over id, title and description. Without either, the most recent CVEs (trimmed to limit). Search and list return { "count", "cves": [...] }.

Returns the cve:recent Redis document as a JSON array (or object), truncated to limit.

Pass ip for full ASN/org data via ipwho.is, or asn (e.g. AS15169 or 15169) for a minimal ASN record.

Domains hosted on an IPv4 address via HackerTarget (one domain per line).

Historical reputation timeline for a domain or IP (entity), optional days window.

On-demand related AlienVault OTX pulses for a given pulse id. Requires pulseId. Returns { "related": [...] }. Uses the public OTX API (optional OTX_API_KEY improves rate limits).

limit (default 30, max 100). Optional press=true adjusts filtering (see server).

Reads ransomware:stats from Redis.

Without sector, returns all sectors. With sector, returns drill-down for that vertical. Optional press flag.

Daily sector-risk snapshots from Redis (ransomware:sector-risk:snapshots). days defaults to 30 (max 120). Optional sector filters to one vertical.

Requires sector. Enriches victims, risk level, top groups.

limit (default 50, max 100). Optional groups — comma-separated group names to filter.

Requires group — full threat-actor aggregate (TTPs, victims, etc.).

Returns the normalized list of tracked ransomware groups (cached from ransomware.live as ransomware:groups:all, ~6h TTL). limit defaults to 100 (max 500). When the claim history is cached, each group also carries claims30d, claimsPrev30d, lastClaimAt and firstClaimAt, and activity gives the 30-day window totals.

Returns source:statistics from Redis (success, data, timestamp). 404 if cache empty.

Requires X-License-Key with an active key from license_keys, plus X-API-KEY or session. Returns cached sources:all JSON or embedded sources.json fallback.

POST /search?keywords=<term> — scans Redis keys with pattern *{keywords}* (glob * stripped from input). Caps at 500 hits / 50 iterations. Returns raw Redis key strings in hits.

Returns default and api_roots pointing to /taxii/api-root (same for /taxii2).

Lists available collections (collections array) for this API root.

Same collection list as embedded in API root (dedicated path).

Metadata for a single collection id (e.g. malicious-domains).

On every shared collection (not the org-reported-* ones) the object also carries three custom properties from the corpus walk (every 12 hours): x_ismalicious_score_histogram (indicator counts per ten-point score band, "0-9" … "90-100" — the same score min_score/max_score filter on, so "60-69" is the size of min_score=60&max_score=69), x_ismalicious_total and x_ismalicious_computed_at. Use them to size a band before polling it. They are absent until the first walk after a deploy.

Returns one page of the collection (identity + indicators) from Redis-backed threat data, as a STIX 2.1 bundle {"type": "bundle", "id", "objects", "more", "next"}: the identity first, then the indicators newest-created first. It carries the fields of a TAXII 2.1 envelope (more, next, objects), so TAXII clients and bundle readers parse the same body. The content type follows Accept:

•Accept: application/taxii+json;version=2.1 (or application/taxii+json): served as application/taxii+json;version=2.1, with the X-TAXII-Date-Added-* headers to the microsecond and match[type|id|version|spec_version] applied. TAXII 2.1 clients built on taxii2-client, such as the OpenCTI connector and the MISP modules, require this content type.

•Any other Accept, or none: served as application/stix+json;version=2.1, unchanged.

Without match[...] and with limit of 2 or more, both forms return the same objects in the same order and the same pages.

Authentication: X-API-KEY (Base64 apiKey:apiSecret) — Pro subscription required.

Performance: Each request examines at most a fixed number of Redis keys (currently 8,000). If your filters match rarely (e.g. a narrow time window), a page may return fewer than limit indicators even when X-TAXII-Has-More is true — call again with next until the feed is exhausted.

End of a walk: more: false ends the walk, even when that last page is empty. Start the next poll from the first page (without next), with added_after set to when that walk started: with Accept: application/taxii+json, the last page's X-TAXII-Date-Added-Last gives that time, less ten minutes. A next token only continues its own walk: pages follow storage order, not the date added, so re-sending the last token returns that last page again, never newer objects. Each page filters on the added_after it carries: repeat it on every page. Clients built on taxii2-client are the exception: there a page that omits added_after filters on its walk's, and a token sent to another collection or with another added_after starts a new walk.

Date filters: added_after and added_before are compared with the date each indicator was added to the collection (TAXII date_added). Indicators written before we recorded that date use their source's firstSeen, else lastSeen; indicators with none of these are excluded when either filter is set (they cannot be placed in a time window). Indicators without intel timestamps still appear in the bundle when no date query parameters are used.

Full-collection ingestion: For complete feed collection, omit both `added_after` and `added_before`. This returns the most complete dataset — including indicators without intel timestamps — and pagination with next behaves identically. Apply date filters only for incremental/windowed pulls where excluding timestamp-less indicators is acceptable.

Recommended polling cadence: once a day. The shared collections are rebuilt by a nightly reload that starts at 02:00 UTC and repopulates the entities this endpoint reads. Responses are computed live — there is no cache in front of them — so the freshness ceiling is that rebuild, not a TTL. Schedule your poll a few hours after it (06:00 UTC is a safe default; the reload's finish time is not tightly bounded) and one call picks up the whole day's new indicators.

Polling more often is permitted and simply returns the same set: added_after is matched against the date each indicator was added to the collection, which only advances when that reload runs. If you would rather notice a delayed or re-run reload without waiting a day, hourly is a sensible ceiling — that buys promptness of noticing, not fresher data. This is guidance, not a quota: no poll interval is enforced, and your plan's per-minute burst limit is the only thing that will stop you.

Exception: the org-reported-* collections are built from your own approved submissions rather than from the nightly reload, so they change as you submit. Poll those as often as your workflow needs.

Response headers:

Filters: match[type], match[id], match[version] and match[spec_version] apply only with Accept: application/taxii+json; otherwise they are ignored. match[id] still walks the whole collection to find an id.

Observables collections: each collection id has a twin ending in -observables (malicious-ips-observables, …), not listed by Get Collections. It walks the same indicators and returns each one as a STIX 2.1 observed-data object holding its IP address, domain, URL or file hash in the objects container, for tools that import observables rather than indicator patterns. It carries no revocations, so an indicator retired from isMalicious is never withdrawn from a tool that reads a twin: where removal matters, the blocklists, full snapshots, are the better source.

Manifest and lookups: GET .../collections/{collectionId}/manifest answers the same query with one record per object (id, date_added, version, media_type). GET .../objects/{objectId} and .../versions serve the isMalicious identity; an indicator cannot be looked up by id (404).

Batch submit up to 100 indicators. Duplicates upsert by (organization, type, value). Returns auto-approved rows.