Get Scan
Get a scan by ID.
Request
- Base URL: https://app.kaminari.ad
- URL: https://app.kaminari.ad/api/v1/scans/{scan_id}
- Auth: HTTP bearer
Path parameters
Response
Successful Response
Status of a scan through its lifecycle.
Ordered: pending(0) → running(1) → crawled(2) → checking(3) → checking_async(4) → terminal(5). Forward-only transitions enforced by advance_status() in the DB (see status_order() Postgres function).
CHECKING_ASYNC means all inline parts (regexp + domain checks) have been applied and we are waiting only on async parts (LLM batch today, SafeBrowsing / VirusTotal tomorrow). UI can show partial tags + alerts at this stage; only classification is still pending.
RECHECKING is a transient state used only by the recheck flow. The recheck use case atomically moves a scan from a terminal state into RECHECKING, wipes prior tags (CH tombstones), wipes scan_part_state, then atomically transitions to CHECKING with fresh expected_parts. Both transitions bypass the forward-only advance_status() guard via dedicated repository methods.
Why RECHECKING exists: stale check.parts.* messages for a now- rechecking scan must NOT write tags (those would survive the wipe without tombstones, corrupting the post-recheck tag set). Consumers check WRITE_BLOCKED_STATUSES and skip the message when the scan is in RECHECKING. Defence in depth — the TagWriterAdapter's UoW also re-reads the scan status before save.
The sibling scans this request also created, excluding this one. Populated only by the create endpoints — list and detail responses leave it empty.
Changes
No recorded changes to this operation across all 1 revision of this API.