Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.tumban.com/llms.txt

Use this file to discover all available pages before exploring further.

A scan is a single profile URL being analyzed. A batch is a set of scans submitted together; each profile in a batch is processed independently.

​
Lifecycle

When you submit a scan, Tumban returns a scan_id and begins processing asynchronously. The scan moves through these statuses:
StatusMeaning
processingThe scan is in flight.
completedAll analysis steps finished successfully.
completed_with_partialResult is usable, but at least one step failed (timeout, blocked link, etc). Inspect the coverage object to see what was skipped.
failedThe scan could not produce a triage report. The error field explains why.
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 from POST /api/v2/scan. Use it to fetch the scan via GET /api/v2/scans/{scan_id}.
  • batch_id — UUID returned from POST /api/v2/batch. Single scans get a synthetic single_<scan_id> batch id for internal bookkeeping; you don’t need it for single scans.

​
Deduplication

Tumban canonicalizes the submitted URL and treats the canonical form as a unique key per organization. Re-submitting the same canonical URL archives the previous scan and starts a new one, so the most recent result is always the one you read back.