How ThreatMap works

One lookup, shared execution

  1. Authenticate the session or API key and resolve current account state.
  2. Validate a single IOC; enforce email verification, scope, plan, rate, and credits.
  3. Select configured, enabled, applicable providers using user preferences and BYOK.
  4. Use scoped cached results where eligible; call providers with bounded deadlines.
  5. Normalize source context and native reputation, preserving failed/skipped statuses.
  6. Build the aggregate, settle credits, and return data with attribution and metadata.

Source reputation and aggregate score

Provider-native reputation remains attributable to that provider. Supported native numeric values are normalized and combined using reliability weights. Context-only data does not acquire an invented per-provider score. Missing reputation remains absent; successful context without numeric risk can produce a clean-consensus aggregate fallback.

ThreatMap aggregate bands are clean (0–20), suspicious (21–40), malicious (41–70), and critical (71–100). Review source evidence alongside the summary; a clean score is not a guarantee that an IOC is safe.

Storage and background work

RelataDB stores application records through its HTTP APIs. Security-critical writes require synchronous confirmation. Production shared session state and durable monitor queues require the configured Redis protocol endpoint.

Monitor checks acknowledge queued work with 202 and a run ID. Workers record progress and deliver configured email, webhook, or Slack alerts asynchronously.

REST and MCP

Stdio and HTTP MCP proxy REST execution, sharing authorization, provider behavior, and charging. HTTP discovery and execution require credentials; stdio discovery is local, while execution needs an API key. BYOK removes source surcharges, not the base search credit. Latency and availability vary with provider and deployment health; no fixed sub-second guarantee applies.