Reconhecer e dispensar pela API

Além de ler, sua automação pode agir: reconhecer (ACK), comentar, fechar e mudar a severidade de incidentes, dispensar alertas de webhook presos e descobrir as fontes de dados da empresa. Estas cinco rotas exigem o token svc_ (ver Autenticação, erros e limites).

Reconhecer incidentes (ACK)

POST/api/v1/svc/incidents/ack

Aplica uma ou mais operações de ACK a um lote de incidentes. O lote pode misturar incidentes do Zabbix e de webhook: o servidor os separa por origem e, no caso do Zabbix, agrupa por servidor e envia um event.acknowledge para cada um.

Campo	Tipo	Obrigatório	Descrição
`incident_ids`	array de inteiros	Sim	1 a 500 ids do Sentrya (o campo `id` da listagem).
`acknowledge`	booleano	Não	Marca como reconhecido ("Confirmar (acknowledge)").
`message`	texto, até 2048	Não	Comentário. Texto não vazio já conta como operação e vai para o Histórico de ACKs.
`close`	booleano	Não	"Fechar problema" no Zabbix. Recusado se o lote tiver webhook.
`change_severity`	booleano	Não	"Mudar severidade". Exige `severity`.
`severity`	inteiro 0–5	Com `change_severity`	Nova severidade.

Pelo menos uma operação precisa estar presente: acknowledge, message, close ou change_severity.

curl -s -X POST https://app.flowbix.com/api/v1/svc/incidents/ack \
  -H "Authorization: Bearer svc_SEU_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "incident_ids": [48213, 48214],
    "acknowledge": true,
    "message": "Equipe de campo acionada, chamado #4471"
  }'

{"acked": 2}

acked é a quantidade de incidentes efetivamente processados. Ids que não existem na sua empresa são ignorados sem erro; se nenhum casar, a resposta é 422.

Como cada origem se comporta

Origem	Reconhecer	Mensagem	Fechar	Mudar severidade
Zabbix	Envia ao Zabbix e reflete no Sentrya na hora	Envia ao Zabbix e grava no histórico	Envia ao Zabbix (a trigger precisa permitir fechamento manual)	Envia ao Zabbix e reflete no Sentrya
Webhook	Só marca no Sentrya	Grava no histórico	Recusado com `422`; use dispensar	Reflete no Sentrya

Um incidente de webhook que já foi resolvido ou dispensado entre a leitura e o ACK é pulado em silêncio e não entra em acked.

ACK pela API não tem autor pessoal. O token svc_ não está vinculado a nenhum usuário, então o event.acknowledge sai com a credencial que a empresa cadastrou no servidor Zabbix (a mesma da coleta), e não em nome de uma pessoa como acontece com o Vínculo do usuário com o Zabbix. No Histórico de ACKs do app a linha aparece sem nome de autor. Se a rastreabilidade individual importa, use message para dizer quem ou o que acionou.

Erros

Status	`error`	Quando
`400`	`payload inválido: …`	JSON inválido, `incident_ids` ausente, vazio ou com mais de 500 itens, `message` acima de 2048.
`400`	`payload inválido: severity deve estar entre 0 e 5`	`change_severity` com `severity` fora da escala.
`400`	`informe ao menos uma operação (acknowledge, message, close ou change_severity)`	Nenhuma operação no corpo.
`422`	`nenhum incidente encontrado para reconhecer`	Nenhum id pertence à sua empresa.
`422`	`incidente não pode ser reconhecido (origem não suportada)`	Incidente com origem inconsistente (sem servidor nem evento).
`422`	`incidentes de webhook não podem ser fechados pelo ACK; use dispensar`	`close: true` com pelo menos um webhook no lote. Nada é aplicado, nem aos Zabbix do lote.
`422`	`este problema não pode ser fechado manualmente: a trigger no Zabbix não permite fechamento manual. Você ainda pode reconhecer (ACK) o problema.`	Zabbix recusou o `close` por falta de "Allow manual close" na trigger.
`422`	`o Zabbix recusou a operação: …`	Outro erro de API do Zabbix; o texto original vem depois dos dois-pontos.
`422`	`não foi possível conectar à URL informada` · `a URL não respondeu como uma API Zabbix` · `o Zabbix recusou o token de API` · `falha ao verificar a conexão`	Problema de rede ou credencial no servidor Zabbix do cliente.

Lotes com vários servidores Zabbix não são atômicos. Cada servidor recebe sua chamada em sequência. Se o segundo falhar, o primeiro já foi reconhecido e a resposta é o 422 do que falhou. Ao repetir, ids já reconhecidos são reenviados sem prejuízo.

Reconhecer pelo evento do Zabbix

POST/api/v1/svc/incidents/ack-external

Reconhece um incidente do Zabbix pela identidade do evento, útil quando você tem o external_id e o servidor, mas não o id do Sentrya. Sempre faz acknowledge; fechar e mudar severidade só na rota anterior. Só funciona para Zabbix.

Campo	Tipo	Obrigatório	Descrição
`external_id`	texto	Sim	Identificador do evento como o Sentrya o armazena.
`zabbix_server_id`	inteiro ≥ 1	Sim	Servidor Zabbix dono do evento.
`message`	texto, até 2048	Não	Comentário anexado ao ACK.

curl -s -X POST https://app.flowbix.com/api/v1/svc/incidents/ack-external \
  -H "Authorization: Bearer svc_SEU_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"external_id": "srv3:ev918273", "zabbix_server_id": 3, "message": "visto pelo bot"}'

{"acked": 1}

Erros: 400 payload inválido: … para corpo incompleto; 422 nenhum incidente encontrado para reconhecer quando o par não existe na empresa ou não é de Zabbix; e os mesmos 422 de recusa do Zabbix listados acima.

Dispensar alertas de webhook

Incidentes de webhook não têm um Zabbix por trás para resolvê-los. Quando a fonte nunca manda o evento de resolução, o alerta fica preso e o caminho é dispensá-lo, o mesmo botão Descartar alerta do app (ver Descartar alertas de webhook). Dispensar marca o incidente como resolvido; ele não é apagado e continua contando recorrência.

Em lote

POST/api/v1/svc/incidents-dismiss

curl -s -X POST https://app.flowbix.com/api/v1/svc/incidents-dismiss \
  -H "Authorization: Bearer svc_SEU_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"incident_ids": [50121, 50122, 50123]}'

{"dismissed": 2}

incident_ids aceita de 1 a 500 ids. Só incidentes de webhook ativos da sua empresa são dispensados; ids de Zabbix, de outra empresa ou já resolvidos são ignorados, e dismissed informa quantos mudaram. Corpo inválido devolve 400 payload inválido: ….

Um por vez

POST/api/v1/svc/incidents-dismiss/:id

curl -s -X POST https://app.flowbix.com/api/v1/svc/incidents-dismiss/50121 \
  -H "Authorization: Bearer svc_SEU_TOKEN"

{"dismissed": true}

Status	`error`	Quando
`400`	`id inválido`	`:id` não é inteiro positivo.
`422`	`incidente não pode ser dispensado (não é de webhook ativo)`	Não existe na empresa, é de Zabbix ou já não está ativo.

Listar fontes de dados

GET/api/v1/svc/webhooks

Lista as Fontes de Dados (webhooks) da empresa. Existe para que uma automação descubra para onde enviar alertas sem que alguém copie o token à mão: o id serve de filtro environment_id na listagem e o ingest_token autentica o POST /api/v1/alerts.

curl -s https://app.flowbix.com/api/v1/svc/webhooks \
  -H "Authorization: Bearer svc_SEU_TOKEN"

{
  "sources": [
    { "id": 12, "name": "Scripts de backup", "ingest_token": "whk_…", "created_at": "2026-05-02T18:20:07Z" }
  ]
}

Esta rota expõe o token de cada fonte. Quem tem o whk_ consegue abrir e resolver alertas naquela fonte. Trate a resposta como segredo: não registre em log, não repasse a terceiros. Se um ingest_token vazar, remova a fonte e crie outra (ver Criar uma fonte de dados).