Webhooks
Receba notificações automáticas do bitERP quando recursos são criados, atualizados, removidos ou restaurados.
Webhooks invertem o sentido da integração: em vez de a sua aplicação perguntar à API se algo mudou, o bitERP avisa você assim que a mudança acontece. Você registra uma URL HTTPS, escolhe os eventos que interessam e passa a receber um POST assinado a cada ocorrência.
É a alternativa recomendada ao polling. Uma rotina que chama GET /sales-orders de minuto em minuto gasta requisições, atrasa a reação e ainda perde alterações que aconteceram e foram desfeitas entre duas leituras. Com webhooks você reage ao fato, não à varredura.
Webhooks não são configurados pela API
O cadastro de endpoints é feito no painel do bitERP, por um administrador da empresa. A API de Integrações não expõe endpoints de webhook — ela é usada depois, para buscar o estado completo do recurso que mudou.
Como funciona
- Alguém altera um recurso no bitERP — pelo painel, pela API de Integrações, pelo MCP ou por uma automação interna.
- O bitERP identifica que a mudança corresponde a um evento assinado pelo seu endpoint.
- Uma entrega (delivery) é criada e enviada como
POSTpara a sua URL, com assinatura HMAC. - O seu servidor responde
2xx. Se não responder, o bitERP repete a entrega com intervalos crescentes. - O payload identifica o que mudou, não o estado do recurso — você busca os dados atuais via API de Integrações.
Configurar um endpoint
Requer permissão de administrador
Os recursos webhook-endpoints e webhook-deliveries são restritos a administradores
da empresa. Usuários comuns e API Keys não acessam essa configuração.
- Acesse o painel do bitERP em app.biterp.ai.
- Navegue até Configurações > WebHooks.
- Clique em Novo Webhook de saída.
- Informe um nome (identificação interna) e a URL que vai receber os
POST. - Selecione os eventos que deseja assinar — ver Eventos.
- Salve. O signing secret é exibido uma única vez: copie e guarde em local seguro.
O secret tem o formato whsec_ seguido de 64 caracteres hexadecimais e é a chave usada para verificar a assinatura de cada entrega. Se você perdê-lo, é possível gerar um novo pelo painel, em Trocar segredo — o secret anterior deixa de valer imediatamente, então atualize a sua aplicação logo em seguida.
Requisitos da URL
| Regra | Detalhe |
|---|---|
| Protocolo | https obrigatório. http só é aceito fora de produção |
| Endereço | Precisa resolver para um IP público e roteável |
| Endereços bloqueados | localhost, faixas privadas (RFC 1918), link-local, CGNAT, multicast e equivalentes IPv6 |
| Unicidade | A mesma URL não pode ser cadastrada duas vezes na mesma empresa |
| Tamanho | Até 2.048 caracteres |
A validação acontece no cadastro e de novo antes de cada entrega. Um domínio que passe a apontar para um endereço interno depois do cadastro tem as entregas recusadas — o que conta como falha e alimenta o circuit breaker.
Túneis de desenvolvimento
Para testar localmente, exponha a sua máquina com um túnel HTTPS público (ngrok,
Cloudflare Tunnel, localtunnel). Apontar o endpoint direto para localhost ou para um
IP da sua rede interna é recusado.
Testar a conexão
Na tela do endpoint, a ação Testar conexão envia imediatamente um POST assinado com o evento webhook-endpoints.test e mostra o status HTTP, o corpo da resposta e o tempo de resposta. É a forma mais rápida de validar que a URL está acessível e que a sua verificação de assinatura funciona.
O teste é síncrono e avulso: não gera uma entrega, não aparece no histórico e não conta para as retentativas nem para o circuit breaker.
Status do endpoint
| Status | O que significa |
|---|---|
| Ativo | Recebendo entregas normalmente |
| Desativado (manual) | Desligado por um administrador; nenhum evento novo é enfileirado |
| Desativado (circuit breaker) | Desligado automaticamente após falhas consecutivas — ver Entrega e retentativas |
Ao reativar um endpoint que estava desativado, o bitERP faz um backfill automático da janela em que ele esteve fora, gerando as entregas que não chegaram a existir. Você recebe os eventos atrasados sem precisar de nenhuma ação.
Limites e garantias
| Aspecto | Comportamento |
|---|---|
| Latência típica | Menos de um minuto após a operação |
| Timeout por tentativa | 10 segundos |
| Tentativas por evento | Até 20, com backoff exponencial |
| Janela total de entrega | Cerca de 2 dias e 20 horas |
| Entregas por empresa | Até 1.000 por hora |
| Histórico de entregas | 30 dias |
| Ordem de entrega | Não garantida — ver Entrega e retentativas |
| Entrega duplicada | Possível — trate o consumo de forma idempotente |
O teto por hora descarta eventos
Ao ultrapassar 1.000 entregas em uma hora, os eventos seguintes da empresa não são
enfileirados — eles não chegam com atraso, simplesmente não chegam. Assine apenas os
eventos que a sua integração realmente consome, especialmente em recursos de alto
volume como financial-transactions.
Próximos passos
Eventos
O catálogo completo do que você pode assinar e o que dispara cada evento.
Receber e verificar
Headers, payload, verificação da assinatura HMAC e como responder.
Entrega e retentativas
Idempotência, ordem, backoff, circuit breaker e diagnóstico.
API de Integrações
Busque o estado completo do recurso que mudou.

