Skip to main content
The Findings Export is a read-only, organization-wide feed of your security findings. It exists for machines: a GRC platform, a SIEM, a compliance warehouse, or any internal job that needs the whole picture on a timer rather than one project at a time in the dashboard.
This is a public contract. Field names are snake_case, and every optional field is always present. When there is no value for a field, it is explicitly null, so a consumer can tell “never triaged” apart from “field missing”.

Endpoint

Authenticate with a bearer token, exactly as elsewhere in the API. Use the base URL of the region your organization is hosted in: https://api-eu.cybedefend.com (EU) or https://api-us.cybedefend.com (US).

Scope

The export covers the projects your token has access to. The project_id filter can only narrow that set, never widen it.

Query parameters

List parameters accept both spellings and any mix of the two:
A mistyped filter fails loudly. It never widens the scope.An unknown value (?status=confimed), an unrecognised parameter name (?statuss=), or a filter that is present but empty (?status=) all return 400. On a compliance feed, silently dropping a filter would return your entire organization while you believed you asked for one status, so the API refuses the request instead.

Response

Notable fields

Survives reindentation, line drift and scanner rule renames. It does change when the file is renamed, when the vulnerable code itself changes, or when one of several identical occurrences in a file disappears.
Computed from the CVSS 4 environmental score, falling back to the base score. none is a real band (a CVSS score of exactly 0) and is exported.
null where the source carries none, such as OSV advisories (sca) and container findings. A null here means “we have no guidance”, not “no action needed”.
File and line for sast, package for sca, image for container, and so on. null when no structured details are available for the finding.

Paginating one pull

Follow next_cursor until has_more is false. Results are sorted ascending on updated_at.
updated_at is the sort key, so a finding modified mid-pagination moves forward in the stream and is delivered again. Consumers must be idempotent on id.

Pulling incrementally

Store the next_since of your last page and replay it verbatim as updated_since on the next run. That is the whole contract: you do not compute the watermark yourself.
next_since is set a few seconds before the last row served, so that consecutive runs overlap slightly. This guarantees that no finding is skipped. Overlap is cheap, a missed finding is not.

Rate limiting

A GRC platform polls on a timer, so 429 is part of this contract, not an error path. Back off and retry.