API REST

Sentry

Los errores que envía Sentry y las conexiones con él.

  • GET /sentry/errors (tracker:read): errores que envió Sentry (?project=MOB para un proyecto, con la integración y el último aviso; ?waiting=true solo los que esperan decisión, como en la pantalla aqua). El mismo error aparece una vez, con events, users, releases y state: pending (juntando avisos antes del triaje), suggested (aqua hizo el triaje), linked, regressed (volvió después de completarse la issue; tracker ya comentó en la issue), merged, dismissed o muted. triage.issue es la issue que escribió aqua y candidate, la issue abierta que parece la misma.
  • POST /sentry/errors/{id} (tracker:write): decide como en la pantalla aqua, {"action": "create_issue", "title": "..."} (crea la issue completada, con enlace, alcance, release, entorno y stack resumido), {"action": "link", "issue": "MOB-0012"} (sin issue, la candidata de aqua; comenta en la issue), {"action": "reopen"} (un error que volvió) o {"action": "dismiss", "snooze": "7"} ("1", "7", "30" o "forever"). Exige editar issues en el proyecto.
  • GET /sentry/connections (tracker:read, admins y dueños): las conexiones con Sentry de la empresa, cada una con project (el proyecto que recibe lo que sobra), webhook_url, secret_saved, sentry_project_targets (la tabla: {"sentry_project": "mi-backend", "target": "MOB"}, con target el prefijo del proyecto, rules o ignore), new_sentry_projects (rules o ignore), rules (en orden, "/v1/pedidos/* → API" o "project=APP → APP"), environments, min_level, start_after, ai_triage, seen (proyectos de Sentry y entornos que ya mostraron los avisos), el último aviso y waiting. GET /sentry/connections/{id} trae una.
  • POST /sentry/connections (tracker:write, admins y dueños): conecta un Sentry, {"project": "MOB"}; la respuesta trae webhook_url para crear la Internal Integration en Sentry (Settings → Custom Integrations), y el client_secret que muestre Sentry entra después. PATCH /sentry/connections/{id}: solo cambia lo que venga, {"client_secret": "...", "sentry_project_targets": [...], "new_sentry_projects": "ignore", "rules": ["/v1/pedidos/* → API", "project=APP → APP"], "environments": ["prod"], "min_level": "error", "ai_triage": true, "active": true, "start_now": true} (la tabla y las reglas vienen enteras; project cambia quién recibe lo que sobra). En la ruta, un * al final es prefijo; sin * vale la ruta y lo que está debajo de ella. DELETE /sentry/connections/{id} desconecta (los errores recibidos se van, las issues creadas quedan).
  • POST /sentry/connections/{id}/test (tracker:read, admins y dueños): adónde irían los últimos errores de la conexión (hasta 20), con la configuración guardada o con sentry_project_targets, new_sentry_projects, rules, environments y min_level del cuerpo, sin guardar. Cada elemento trae result (project, ignored u outside_environment), project (prefijo), by (table, rule con rule, el número de la regla, o leftover), below_min_level, now_in, route y tags. En el MCP: list_sentry_connections, save_sentry_connection y test_sentry_connection.