Svix
Serviço de webhooks de código aberto: envie eventos aos seus clientes com retentativas, assinatura e histórico de entrega
Svix é um serviço de código aberto e auto-hospedável para enviar webhooks aos seus próprios clientes: você faz uma chamada de API e ele cuida da entrega, das retentativas, da assinatura do payload e do histórico por endpoint. Tem licença MIT, é escrito em Rust e tinha 3.376 estrelas no GitHub em agosto de 2026. Para um time pequeno, transforma o "precisamos suportar webhooks" de duas semanas de encanamento de filas em uma tarde — e isso importa mais do que parece, porque webhooks de saída são a superfície de integração mais barata que você consegue oferecer, e integração é distribuição.
O que é o Svix
O Svix (github.com/svix/svix-webhooks) é o despachante de código aberto por trás do serviço hospedado da Svix. Sua aplicação faz uma única chamada de API para enviar uma mensagem aos endpoints de uma aplicação; a partir daí o Svix assume tudo. Ele sobe pelo próprio arquivo Docker Compose do repositório, que também inicia as duas dependências necessárias: PostgreSQL para armazenamento e Redis — opcional, versão 6.2.0 ou superior — para a fila de tarefas e o cache. As bibliotecas oficiais cobrem Go, Python, TypeScript, Java, Kotlin, Ruby, C#, Rust e PHP, além de um provider Terraform e uma CLI que você roda direto pelo npm.
- Payloads assinados. Chaves simétricas pré-compartilhadas por padrão; o README coloca a assinatura simétrica em cerca de 50 vezes mais rápida para assinar e 160 vezes mais rápida para verificar do que a opção assimétrica ed25519, que também é suportada para quando você prefere distribuir uma chave pública em vez de um segredo.
- Retentativas e fila de mensagens mortas. Erros internos repetidos acabam colocando uma tarefa numa DLQ, e o README manda acompanhar a profundidade dela por uma métrica dedicada e reprocessá-la a partir de um endpoint administrativo depois que a causa for resolvida.
- Proteção contra SSRF. Envios para endereços IP internos são bloqueados por padrão, com uma lista de sub-redes liberadas para o caso em que o destinatário é mesmo interno.
- Webhooks operacionais. O servidor consegue mandar webhooks sobre ele mesmo, então você descobre que um cliente desativou ou alterou um endpoint sem precisar ficar consultando.
O README é incomumente direto sobre os próprios limites: o serviço hospedado tem recursos, otimizações e comportamentos que ainda não estão no repositório, e os dois são descritos como quase compatíveis, mas não totalmente. Vale ler antes de assumir paridade com a versão aberta.
Por que webhooks são superfície de crescimento, e não só encanamento
Webhooks são arquivados como assunto de engenharia, e por isso ficam sempre para o próximo trimestre. Esse arquivamento é um erro. Um webhook de saída é a única integração que você constrói uma vez e nunca mais: depois que ela existe, seus clientes te conectam ao Zapier, ao n8n, aos scripts internos deles e ao que mais já usarem, e cada um desses é uma parceria que você não precisou negociar. Nossa página sobre vale a pena construir integrações desenvolve o argumento completo; webhooks são a linha mais barata daquela tabela.
- Distribuição sem parcerias Um endpoint só coloca você dentro de todas as ferramentas de automação que seus clientes já pagam, sem publicar um conector para nenhuma delas.
- Retenção que você não precisou defender Um cliente cujo sistema interno reage aos seus eventos tem um custo de troca que nenhuma tabela comparativa cria.
- Um suporte mais barato "Por que não disparou?" se responde a partir de um registro de entrega que o cliente enxerga, e não dos seus logs às onze da noite.
- Um motivo para escrever documentação que as pessoas leem Payloads de eventos são das raras páginas de documentação que viram favorito, o que as torna ótimas candidatas a ranquear.
O que aprendemos estando do lado que recebe
Nós não enviamos webhooks em escala; consumimos muitos, para pagamentos, para chat e para cada integração que nossos agentes tocam. Saíram dois hábitos disso, e ambos são decisões que você também toma do lado de quem envia. Primeiro: quem recebe deve responder 200 e registrar o evento mesmo quando o recurso que o consome está desligado, porque qualquer outra coisa faz o remetente repetir, e uma tempestade de retentativas é pior do que um evento que você ignora. Segundo: todo handler precisa ser seguro para rodar duas vezes, porque o mesmo evento vai chegar duas vezes. Isso não é bug de quem envia: é o que entrega ao menos uma vez significa.
A imagem espelhada do lado de quem envia é o que erramos em outro lugar e não repetiríamos: sucesso de transporte não é sucesso de ação. Uma vez registramos um post como publicado porque a chamada HTTP retornou 200, enquanto o corpo abaixo dizia que ele havia sido rejeitado. Se você é quem envia webhooks, faça o registro de entrega refletir o que o corpo do destinatário disse, não o que a linha de status dizia — e dê aos clientes o histórico para que possam conferir você. Lançar webhooks não traz ninguém sozinho; anunciá-los aos clientes que pediram, documentar os payloads e aparecer onde os usuários de automação procuram é o que traz. Essa metade é o mesmo trabalho de crescimento de sempre, e é para isso que existe a AgentCeres — the AI Growth Officer, em agentceres.com: os agentes rascunham o anúncio, a página de documentação e o contato, e uma pessoa aprova o que sai.
FAQ
- Auto-hospedar o Svix é gratuito?
- Sim. O repositório tem licença MIT e o servidor sobe pelo próprio Docker Compose com PostgreSQL, mais Redis se você quiser a fila e o cache em Redis. A mesma empresa vende uma versão hospedada, e o README é explícito ao dizer que o despachante de código aberto não tem todos os recursos e otimizações do serviço hospedado. Vale conferir contra os seus requisitos em vez de supor que são o mesmo produto.
- Eu preciso mesmo de Redis?
- Não necessariamente: o README lista PostgreSQL como obrigatório e Redis como opcional, usado para a fila de tarefas e o cache. Se você for usar, há duas notas de configuração do README fáceis de perder e caras de aprender: habilite persistência para que tarefas na fila sobrevivam a um reinício, e ajuste a política de despejo para que chaves sem expiração explícita nunca sejam removidas.
- Assinatura simétrica ou assimétrica?
- A simétrica é o padrão e a recomendação. É muito mais rápida dos dois lados e bem mais simples de verificar para os seus clientes, ao custo de um segredo compartilhado por endpoint. A assinatura assimétrica ed25519 existe para quando você prefere publicar uma chave pública a distribuir segredos, o que importa principalmente quando quem recebe são terceiros com quem você não tem relação de suporte.
- Não é melhor eu mesmo construir o envio de webhooks?
- Dá, e a primeira versão é pequena. O que cresce é tudo em volta: backoff exponencial, desativar um endpoint depois de falhas repetidas, proteção contra reenvio, rotação de segredos, um histórico de entrega que seus clientes consigam ler e uma fila que não perca eventos quando o processo reinicia. É a mesma forma de construir-ou-comprar sobre a qual escrevemos em devo construir meu próprio agente de marketing com IA?: o protótipo é um fim de semana, a metade operacional não é.
You built it. Now grow it.
AgentCeres is a managed AI marketing team — specialists draft the SEO, social, and outreach that fill your links, you approve what ships. 14-day free trial, from $39/month.