Scan modes
Every scan runs in one of two modes, chosen by the endpoint you call:
Both modes return the same response shape and the same
triage report fields (
recommendation,
risk_score, confidence, reason_codes, evidence_index). The
submission response and the scan record both carry a scan_mode field
(deep or quick) so you can tell which ran. Because a quick scan
skips steps, read the coverage object to see
what was and wasn’t analyzed.
Use quick scans for cheap, high-volume triage where profile-level
signals are enough; use deep scans when you need the full external
footprint behind a decision.
Lifecycle
When you submit a scan, Tumban returns ascan_id and begins processing
asynchronously. The scan moves through these statuses:
See Status values for the canonical reference.
Concurrency and timing
Tumban processes scans concurrently and enforces a hard 450-second timeout per scan. A typical scan completes in under two minutes. If you submit a batch of N profiles, the estimated completion time scales roughly linearly with batch size while staying within the concurrency cap.Identifiers
scan_id— UUID returned fromPOST /api/v2/scan/deeporPOST /api/v2/scan/quick. Use it to fetch the scan viaGET /api/v2/scans/{scan_id}.batch_id— UUID returned fromPOST /api/v2/batch/deeporPOST /api/v2/batch/quick. Single scans get a syntheticsingle_<scan_id>batch id for internal bookkeeping; you don’t need it for single scans.

