API REST

Sentry

Os erros que o Sentry manda e as conexões com ele.

  • GET /sentry/errors (tracker:read): erros que o Sentry mandou (?project=MOB para um projeto, com a integração e o último aviso; ?waiting=true só os que esperam decisão, como na tela aqua). O mesmo erro aparece uma vez, com events, users, releases e state: pending (juntando avisos antes da triagem), suggested (a aqua fez a triagem), linked, regressed (voltou depois de a issue ser concluída; o tracker já comentou na issue), merged, dismissed ou muted. triage.issue é a issue que a aqua escreveu e candidate, a issue aberta que parece a mesma.
  • POST /sentry/errors/{id} (tracker:write): decide como na tela aqua, {"action": "create_issue", "title": "..."} (cria a issue preenchida, com link, alcance, release, ambiente e stack resumido), {"action": "link", "issue": "MOB-0012"} (sem issue, a candidata da aqua; comenta na issue), {"action": "reopen"} (erro que voltou) ou {"action": "dismiss", "snooze": "7"} ("1", "7", "30" ou "forever"). Exige editar issues no projeto.
  • GET /sentry/connections (tracker:read, admin e dono): as conexões com o Sentry da empresa, cada uma com project (o projeto que recebe o que sobrar), webhook_url, secret_saved, sentry_project_targets (a tabela: {"sentry_project": "meu-backend", "target": "MOB"}, com target o prefixo do projeto, rules ou ignore), new_sentry_projects (rules ou ignore), rules (na ordem, "/v1/pedidos/* → API" ou "project=APP → APP"), environments, min_level, start_after, ai_triage, seen (projetos do Sentry e ambientes que os avisos já mostraram), o último aviso e waiting. GET /sentry/connections/{id} traz uma.
  • POST /sentry/connections (tracker:write, admin e dono): conecta um Sentry, {"project": "MOB"}; a resposta traz webhook_url para criar a Internal Integration no Sentry (Settings → Custom Integrations), e o client_secret que o Sentry mostrar entra depois. PATCH /sentry/connections/{id}: só o que vier muda, {"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} (a tabela e as regras vêm inteiras; project troca quem recebe o que sobrar). Na rota, * no fim é prefixo; sem * vale a rota e o que vem abaixo dela. DELETE /sentry/connections/{id} desconecta (os erros recebidos saem, as issues criadas ficam).
  • POST /sentry/connections/{id}/test (tracker:read, admin e dono): para onde iriam os últimos erros da conexão (até 20), com a configuração salva ou com sentry_project_targets, new_sentry_projects, rules, environments e min_level do corpo, sem gravar. Cada item traz result (project, ignored ou outside_environment), project (prefixo), by (table, rule com rule, o número da regra, ou leftover), below_min_level, now_in, route e tags. No MCP: list_sentry_connections, save_sentry_connection e test_sentry_connection.