Skip to main content
POST
Reopen a resolved or assigned finding

Authorizations

Authorization
string
header
required

An Earnie API key, sent as Authorization: Bearer sk_earnie_.... Create one under Settings > API keys. The key's scopes decide which operations it may call.

Path Parameters

findingId
string<uuid>
required

Body

application/json
expected_version
integer<int32>
required
justification
string

Response

Finding after reopen

id
string<uuid>
required
org_id
string<uuid>
required
project_id
string<uuid>
required
domain_slug
string
required
title
string
required
evidence
object
required
produced_by
object
required
state
enum<string>
required
Available options:
open,
assigned,
resolved,
superseded_by_rule,
reopened
domain
enum<string>
required
Available options:
oss,
crypto,
ai,
deps,
provenance
severity
enum<string>
required
Available options:
critical,
high,
medium,
low,
info,
none
suppressed
boolean
required
version
integer<int32>
required
created_at
string<date-time>
required
updated_at
string<date-time>
required
purpose
enum<string> | null
required

Per-finding crypto purpose. Present for crypto findings and null for other finding domains.

Available options:
confidentiality,
excluded,
support,
unknown
export_signals
object[]
required

Per-finding Export Signals for the current regime, current-vintage rows first. Rows computed under a superseded regime version are still returned, marked vintage: retired; they are never dropped, because a regime bump would otherwise empty this array for every project that has not re-scanned. Other finding domains return an empty array.

location
object | null
producer_kind
enum<string> | null

Which producer last observed this finding.

Available options:
repo,
upload,
pr_ci,
agent
producer_ref
string | null

Human-readable provenance reference (e.g. Null when not set.

previous_severity
enum<string> | null

The severity this finding carried before the most recent re-scan changed it. severity is recomputed and overwritten on every re-scan, so without this the previous value is simply gone. Null means no re-scan has ever moved this finding's severity — it is not "unknown", and it must not be read as "was previously none".

Available options:
critical,
high,
medium,
low,
info,
none
previous_severity_scan_run_id
string<uuid> | null

The scan run this finding was last observed at while it still carried previous_severity, so a client can state the whole fact — "was critical at scan " — instead of an unattributable claim. Null when no transition has been recorded, and also when the earlier observation predates scan-run tracking: a set previous_severity with a null scan run is a real transition whose scan cannot be named.

severity_change_reason
enum<string> | null

Which direction the recorded transition went, and the only field that distinguishes a downgrade from a raise. Null when no transition has been recorded.

Available options:
rescan_lowered,
rescan_raised
enrichments
object

Canonical PURL-keyed enrichments attached at read time.

resolution_id
string<uuid> | null

ID of the resolution that currently explains this finding's resolved state. Null when the finding is open, reopened, or superseded by a rule. Set on resolve; cleared to null on reopen, supersede, or revert. Consumers can use this to fetch the full resolution record in one query rather than replaying audit events.

scan_only
boolean

True when the finding was read from a pull request scan's own result set and no standing project finding carries its id: the pull request introduced it and it has not reached the default branch. It can still be resolved, reopened and approved: the decision is kept by identity and applies when the finding reaches the default branch. Assign, suppress and create-rule answer 409 finding_scan_only until it does. Absent or false everywhere else.

pending_resolution
object

A resolve decision taken on a finding a pull request introduced (scan_only). It is kept by the finding's identity and becomes the resolution it describes when that identity first reaches the default branch. Until then the pull request reads the finding as resolved, and out of its gate when suppresses is true. Present only on a scan_only finding that carries one.