Updating a threat's note

POST /v1/threats/{threat_id}/update-note writes a free-form note onto one of your threats — the same note an analyst edits in MySecutec — so the conclusion your SOAR or your team reached is visible to everyone working that threat.

curl -s -X POST \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"note": "Closed in our SOAR — ticket INC-4821, credential rotated."}' \
  "https://api.secutec.com/v1/threats/5f3b94b1-35ad-49bb-b118-8e8fc24abf80/update-note"

The response is 202 Accepted with an empty body. Nothing is echoed back — see below for why.

The request body

Field	Required	Meaning
note	yes	The new note. Free text with no length limit. It replaces the current note; an empty string stores an empty note.

The body takes nothing else. In particular it does not take a status: a note write never changes the threat's status, and the verdict has its own operation — Updating threat status. Any other key is rejected with a 422 rather than silently ignored, so a request that tries to do both fails loudly instead of half-applying.

The note is applied asynchronously

This is a command: the platform accepts your note and applies it to the threat and to the views built on top of it. A GET /v1/threats/{threat_id} issued immediately afterwards may briefly return the previous note. Do not build a read-back-and-compare loop on this endpoint; if you need confirmation, poll the threat after a short delay.

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

Retries

The gateway forwards your note exactly once — it never retries a write on your behalf. If your request times out, the outcome is unknown: re-sending the same note is safe and reaches the same end state. Writing a note identical to the stored one is accepted (202) and changes nothing.

Errors

Status	type suffix	When
400	request/invalid-filter	{threat_id} in the path is not a UUID
403	auth/insufficient-role	Your credential lacks the role for this operation; nothing is written
404	resource/not-found	No threat with that id exists for your organization; nothing is written
422	request/validation	Malformed body: note missing, not a string, or an unknown field

See Errors for the error format and the full catalog.