Autenticação, erros e limites da API
A API de integração do Sentrya vive em https://app.flowbix.com/api/v1/svc e é autenticada por um token de service account. Esta página reúne o que vale para todas as rotas: header, envelope de erro, códigos de status, formatos e paginação.
Endereço e autenticação
Toda rota desta API começa com https://app.flowbix.com/api/v1/svc. O token vai no header Authorization, no esquema Bearer:
curl -s https://app.flowbix.com/api/v1/svc/incidents/summary \
-H "Authorization: Bearer svc_SEU_TOKEN"
O token identifica a empresa. Você nunca informa org_id em query, corpo ou header: o servidor resolve a empresa a partir do hash do token e isola todos os dados por ela. Um id de outra empresa em qualquer parâmetro simplesmente não casa nada.
Como obter o token: Service accounts: tokens de integração.
/svc não passam pela verificação de e-mail nem pelo bloqueio de período de teste aplicados às sessões de pessoas: um token é uma credencial de máquina. Em troca, a empresa é verificada a cada requisição: suspensa, recusada ou com teste vencido bloqueia o token na hora (403). Empresa aguardando aprovação não bloqueia.Envelope de erro
Toda resposta de erro é JSON com o campo error (texto em português) e, em alguns casos, um code estável para tratar por programa:
{"error": "token inválido"}
{"error": "limite do seu plano atingido", "code": "limit_reached", "limit_key": "max_service_accounts"}
Trate error como mensagem para humanos e decida a lógica pelo status HTTP (e por code, quando existir).
Códigos de status
| Status | Quando acontece | Exemplo de error |
|---|---|---|
200 | Sucesso. Todas as rotas /svc, inclusive as de ação, respondem 200 com corpo JSON. | — |
400 | Query param fora do domínio ou corpo JSON inválido. O nome do parâmetro vem na mensagem. | parâmetro inválido: severity · payload inválido: … · id inválido |
401 | Header ausente, token desconhecido, desativado, revogado ou excluído. Também para qualquer rota fora de /svc chamada com svc_. | token inválido |
403 | Token válido, mas a empresa está suspensa, recusada ou com período de teste vencido. | organização indisponível |
404 | Rota inexistente ou recurso não visível, como um view_id que não existe para esta empresa. | visão não encontrada |
422 | Requisição bem formada, mas a operação não pode ser aplicada: incidente não encontrado, webhook que não pode ser fechado, recusa do Zabbix. | nenhum incidente encontrado para reconhecer |
429 | Limite de requisições por janela. Vem com o header Retry-After (segundos). Hoje nenhuma rota /svc tem esse limite; ele existe em rotas de login da API e pode ser adotado aqui. Trate de forma defensiva. | muitas tentativas, tente novamente mais tarde |
500 | Falha interna. Sem detalhes no corpo, de propósito. Tente de novo com recuo exponencial. | erro interno |
503 | Serviço indisponível. A rota de saúde /ready responde 503 quando MySQL ou Redis estão fora. Transitório. | — |
401 quer dizer que o token não serve mais: confira no painel Integrações se ele foi desativado ou excluído e gere outro. Um 403 significa que o token está certo, mas a empresa está bloqueada: o caminho é comercial, não técnico.Formatos
- Timestamps sempre em RFC 3339 e UTC, por exemplo
"2026-08-26T14:03:11Z". Campos que podem não existir (resolved_at) vêm comonull. - Severidade é um inteiro de 0 a 5 na escala do Zabbix, acompanhado do rótulo
severity_label:not_classified,info,warning,average,high,disaster. No app esses valores aparecem como Não classificado, Informação, Atenção, Média, Alta e Desastre (ver Severidades e estados). - Ids são inteiros positivos. Listas de ids no corpo viajam como array JSON; na query, como CSV (
severity=4,5) ou parâmetro repetido (hosts=a&hosts=b). - Corpo das ações: JSON com
Content-Type: application/json, até 8 KiB. Campos desconhecidos são ignorados.
Paginação
A listagem de incidentes usa limit e offset:
| Parâmetro | Padrão | Limites |
|---|---|---|
limit | 20 | 1 a 100 |
offset | 0 | ≥ 0 |
A resposta devolve o total para você saber quando parar:
{
"incidents": [ … ],
"pagination": { "limit": 100, "offset": 200, "total": 1342 }
}
Toda ordenação tem desempate por id, então paginar por offset não repete nem pula itens entre páginas, mesmo com a lista mudando.
Limites de uso
Não há limite por janela de tempo nas rotas /svc neste momento. Os limites em vigor são de tamanho e de lote:
| Limite | Valor |
|---|---|
| Itens por página na listagem | 100 |
| Ids por chamada de ACK ou dispensar | 500 |
| Corpo de requisição | 8 KiB |
Tamanho de message no ACK | 2048 caracteres |
| Chamada ao Zabbix do cliente durante um ACK | 15 segundos por servidor |
| Service accounts por empresa | max_service_accounts do plano (Planos e limites) |
Seja um bom vizinho: para acompanhar incidentes em tempo quase real, consulte a cada 30 a 60 segundos com sort=newest e lembre o maior id já visto. É o que o Sentrya Trigger do n8n faz.
Rotas disponíveis
O token svc_ é aceito só nestas oito rotas. Qualquer outra responde 401.
| Método | Rota | O que faz | Documentação |
|---|---|---|---|
| GET | /svc/incidents | Lista incidentes com filtros e paginação | Consultar incidentes |
| GET | /svc/incidents/summary | Contagem de ativos por severidade | Consultar incidentes |
| GET | /svc/incidents/activity | Alertas por hora nas últimas 24h | Consultar incidentes |
| POST | /svc/incidents/ack | Reconhecer, comentar, fechar, mudar severidade | Reconhecer e dispensar |
| POST | /svc/incidents/ack-external | ACK de um incidente Zabbix pelo evento | Reconhecer e dispensar |
| POST | /svc/incidents-dismiss | Dispensar incidentes de webhook em lote | Reconhecer e dispensar |
| POST | /svc/incidents-dismiss/:id | Dispensar um incidente de webhook | Reconhecer e dispensar |
| GET | /svc/webhooks | Lista as fontes de dados com o token de ingestão | Reconhecer e dispensar |
Para enviar alertas ao Sentrya não se usa o token svc_: o intake é POST /api/v1/alerts autenticado pelo token whk_ da fonte (ver Referência do payload).