Use an organization API key with Bearer authentication to handle Infrastructure incidents in your own workflows. Every operation is restricted to the key's organization. Incidents represent security-one threat assessments meeting the configured confidence threshold (default 0.8). Routine and inconclusive analysis results are excluded. A high-confidence threat with unknown impact can appear for review without sending a webhook. Later inconclusive results do not overwrite its detection evidence.

List incidents

GET /api/v1/incidents returns summaries ordered by latest activity, then ID, both descending. The response contains data and pagination with limit, offset, total, and has_more.

Unknown or repeated query parameters return 400. Without filters, the list includes all review states, including resolved incidents.

curl "$SUPERAGENT_URL/api/v1/incidents?triage_status=new&severity=high" \
  -H "Authorization: Bearer $SUPERAGENT_API_KEY"

Each summary includes the incident UUID, title, source ID and name, application group, environment, behavior, severity, assessment status and revision, triage_status, triage_resolution, triage_version, first/last seen timestamps, and a relative dashboard_url opening its detail panel.

Get an incident

GET /api/v1/incidents/{incident_id} returns { "data": { ... } } with the summary fields plus the security-one assessment, sanitized log evidence, and:

Keys, webhook credentials, and private replay object paths are excluded. The collections are recent context, not an export of the complete audit history.

Update incident review

PATCH /api/v1/incidents/{incident_id} changes manual review state and returns the full incident under data. Fetch the incident first and send its current triage_version to protect against concurrent reviewers.

curl -X PATCH "$SUPERAGENT_URL/api/v1/incidents/$INCIDENT_ID" \
  -H "Authorization: Bearer $SUPERAGENT_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"triage_status":"resolved","triage_resolution":"false_positive","triage_version":1,"comment":"Expected activity from our deployment."}'

triaging is an automated state and cannot be set manually. Resolving an incident suppresses further webhook escalation for it until reopened. Review updates preserve the security-one assessment, evidence, severity, and assessment status. Each state change increments triage_version and records the validated API key ID in immutable review history. The ID remains after key revocation. Submitting the current state at the current version is a no-op; it does not append a comment or audit record.

A stale version returns 409 with error code conflict; fetch the latest incident, review the intervening changes, and retry with that version. Invalid input returns 400, missing or revoked credentials return 401, and unknown or other-organization IDs both return 404. Errors use the standard { "error": { "code": "...", "message": "..." } } envelope.

MCP tools

The MCP server exposes the same operations as list_incidents, get_incident, and update_incident_triage. Use incident_id for the latter two and the same filters and review fields as the REST API. For an update, read the current version with get_incident before calling update_incident_triage. Authentication supplies the organization and actor.