REST API

Sentry

The errors Sentry sends and the connections to it.

  • GET /sentry/errors (tracker:read): errors Sentry sent (?project=MOB for one project, with the integration and the last notice; ?waiting=true only the ones awaiting a decision, as on the aqua screen). The same error shows up once, with events, users, releases and state: pending (gathering notices before triage), suggested (aqua did the triage), linked, regressed (came back after the issue was completed; tracker already commented on the issue), merged, dismissed or muted. triage.issue is the issue aqua wrote and candidate, the open issue that looks like the same one.
  • POST /sentry/errors/{id} (tracker:write): decides as on the aqua screen, {"action": "create_issue", "title": "..."} (creates the issue filled in, with link, reach, release, environment and a short stack), {"action": "link", "issue": "MOB-0012"} (without issue, aqua's candidate; comments on the issue), {"action": "reopen"} (an error that came back) or {"action": "dismiss", "snooze": "7"} ("1", "7", "30" or "forever"). Requires editing issues in the project.
  • GET /sentry/connections (tracker:read, admins and owners): the company's Sentry connections, each with project (the project that receives whatever is left over), webhook_url, secret_saved, sentry_project_targets (the table: {"sentry_project": "my-backend", "target": "MOB"}, with target the project prefix, rules or ignore), new_sentry_projects (rules or ignore), rules (in order, "/v1/orders/* → API" or "project=APP → APP"), environments, min_level, start_after, ai_triage, seen (Sentry projects and environments the notices have already shown), the last notice and waiting. GET /sentry/connections/{id} returns one.
  • POST /sentry/connections (tracker:write, admins and owners): connects a Sentry, {"project": "MOB"}; the response has webhook_url to create the Internal Integration in Sentry (Settings → Custom Integrations), and the client_secret Sentry shows goes in later. PATCH /sentry/connections/{id}: only what's sent changes, {"client_secret": "...", "sentry_project_targets": [...], "new_sentry_projects": "ignore", "rules": ["/v1/orders/* → API", "project=APP → APP"], "environments": ["prod"], "min_level": "error", "ai_triage": true, "active": true, "start_now": true} (the table and the rules come whole; project changes who receives the leftovers). In a route, a trailing * is a prefix; without * it matches the route and what's below it. DELETE /sentry/connections/{id} disconnects (received errors go away, created issues stay).
  • POST /sentry/connections/{id}/test (tracker:read, admins and owners): where the connection's latest errors would go (up to 20), with the saved settings or with sentry_project_targets, new_sentry_projects, rules, environments and min_level from the body, without saving. Each item has result (project, ignored or outside_environment), project (prefix), by (table, rule with rule, the rule number, or leftover), below_min_level, now_in, route and tags. In the MCP: list_sentry_connections, save_sentry_connection and test_sentry_connection.