Errors

Errors follow RFC 9457 Problem Details: the body is application/problem+json with title, status and a human-readable detail.

{
  "type": "https://tools.ietf.org/html/rfc9110#section-15.5.1",
  "title": "Bad Request",
  "status": 400,
  "detail": "url is required"
}

Validation failures on request bodies return the same shape extended with a per-field errors map.

Status codes you will see

Status	When	What to do
`400`	Malformed body, missing/invalid field, unknown enum value.	Fix the request; the `detail`/`errors` fields say which field.
`401`	Missing, invalid, expired or revoked API key on an endpoint that requires one.	Check the `X-Api-Key` header and the key's status in the dashboard.
`403`	Valid key, but it lacks the scope for this endpoint.	Create a key with the needed scope (see scopes).
`404`	Unknown id — or a private resource your key cannot access.	Verify the id. Note: lack of access is deliberately indistinguishable from non-existence.
`429`	Rate limit or quota exceeded.	Wait `Retry-After` seconds; check `GET /api/usage`.
`5xx`	Transient server-side failure.	Retry with backoff; contact us if it persists.

Scan-level failures are not HTTP errors

A scan that could not complete (unreachable host, blocked egress, timeout) still returns 200 from the polling endpoint — the failure is expressed in the result itself (scanState: "failed" or an unreachable result with a reason), so you can distinguish "the API failed" from "the target could not be scanned".