Skip to main content
GET
List Scans

Authorizations

X-API-Key
string
header
required

Headers

X-Workspace-Id
string | null

Path Parameters

connected_org_id
string<uuid>
required

Query Parameters

limit
integer
default:100

Maximum items to return.

Required range: 1 <= x <= 500
offset
integer
default:0

Items to skip.

Required range: x >= 0

Cookies

riftmap_access
string | null

Response

Successful Response

completed_at
string<date-time> | null
required
connected_org_id
string<uuid>
required
created_at
string<date-time>
required
errors
Errors · object | null
required
failed_repos
integer
required
read-only

Repositories this scan could not process. Non-zero means the dependency graph may be missing edges; the affected repos keep their previous data and are retried on the next scan. It is what makes a scan report status "partial", derived from the same errors dict, so the two cannot disagree — but scans stored before v1.24.4 report "completed" with the same repo_errors, so a client should test status == "partial" or failed_repos > 0. Excludes the enrichment / ownership org-level entries in errors.repo_errors, which are post-scan passes, not repositories.

id
string<uuid>
required
scan_type
string
required
scanned_repos
integer
required
skipped_repos
integer
required
started_at
string<date-time> | null
required
status
string
required

One of pending | running | completed | partial | failed | cancelled. 'partial' is a refinement of 'completed', not a kind of failure: the scan ran the whole loop and its rows are the org's current ones, it just could not process every repository. Only 'pending' and 'running' are in flight, so a poll loop should test those two rather than enumerate the terminal values. Scans stored before v1.24.4 report 'completed' with a non-empty errors.repo_errors and were not backfilled, so the honest test for an incomplete graph is status == 'partial' or failed_repos > 0.

total_repos
integer
required
updated_at
string<date-time>
required
interruption_count
integer
default:0