Updating threat status

PATCH /v1/threats/{threat_id} records your organization's verdict on a threat — the same actions an analyst has in MySecutec, available to your SOAR or automation tooling. It is the API's first write operation.

curl -s -X PATCH \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"status": "false_positive", "status_note": "known scanner, triaged"}' \
  "https://api.secutec.com/v1/threats/5f3b94b1-35ad-49bb-b118-8e8fc24abf80"

The response is the full updated threat, bare — the same object GET /v1/threats/{threat_id} returns, so no follow-up read is needed.

The request body

Field	Required	Meaning
status	yes	Your verdict: unsolved, solved, false_positive or accepted.
status_note	only for accepted	Free-text note explaining the verdict. Accepting a risk needs a reason.

Two things the body does not take:

• pending. It is computed by the platform (see below), never assigned. Sending it answers 400 with type https://api.secutec.com/errors/request/invalid-status-transition:

  {
    "type": "https://api.secutec.com/errors/request/invalid-status-transition",
    "title": "Bad Request",
    "status": 400,
    "detail": "This status cannot be set. Settable statuses: unsolved, solved, false_positive, accepted.",
    "instance": "/v1/threats/5f3b94b1-35ad-49bb-b118-8e8fc24abf80"
  }
  

• Unknown fields. Any key other than the two above is rejected with a 422 rather than silently ignored — if the API accepted-and-dropped it, a future version that adds the field would silently change what your stored requests do.

Read the response — the status you get back can differ

Setting status records your verdict. The status field in the response is the platform's recalculated effective status, and on threats the platform verifies automatically it can legitimately differ from what you sent:

• Marking such a threat solved is a claim of remediation. The effective status becomes pending until the next scan confirms the fix — the response to your PATCH already shows "status": "pending".
• If the next scan still detects the threat, the effective status reverts to unsolved; if the threat is gone, it becomes solved.
• false_positive and accepted are sticky — they hold regardless of what later scans observe.

Always take the effective status from the response body rather than assuming it equals your input.

Retries and the delta stream

The gateway forwards your update exactly once — it never retries a write on your behalf. If your request times out, the outcome is unknown: re-sending the same request is safe and reaches the same end state, but it re-stamps the status-change timestamp.

A successful update bumps the threat's updated_at, so the threat is re-delivered on your next GET /v1/threats delta poll — including updates your own automation just made. De-duplicate on id as usual (see Pagination & deltas).

Errors

Status	type suffix	When
400	request/invalid-status-transition	status is pending
400	request/invalid-filter	{threat_id} in the path is not a UUID
404	resource/not-found	No threat with that id exists for your organization
422	request/validation	Malformed body: unknown status value, missing status_note on accepted, unknown field

See Errors for the error format and the full catalog.