Svix
Servicio de webhooks de código abierto: envía eventos a tus clientes con reintentos, firma e historial de entrega
Svix es un servicio de código abierto y autoalojable para enviar webhooks a tus propios clientes: haces una llamada a la API y él se ocupa de la entrega, los reintentos, la firma del payload y el historial por endpoint. Tiene licencia MIT, está escrito en Rust y contaba con 3.376 estrellas en GitHub a fecha de agosto de 2026. Para un equipo pequeño convierte el "deberíamos soportar webhooks" de dos semanas de fontanería de colas en una tarde, y eso importa más de lo que parece: los webhooks salientes son la superficie de integración más barata que puedes ofrecer, y las integraciones son distribución.
Qué es Svix
Svix (github.com/svix/svix-webhooks) es el despachador de código abierto que hay detrás del servicio alojado de Svix. Tu aplicación hace una sola llamada a la API para enviar un mensaje a los endpoints de una aplicación; a partir de ahí Svix se encarga de todo. Arranca con el propio fichero Docker Compose del repositorio, que además levanta las dos dependencias que necesita: PostgreSQL para el almacenamiento y Redis — opcional, versión 6.2.0 o superior — para la cola de tareas y la caché. Las librerías oficiales cubren Go, Python, TypeScript, Java, Kotlin, Ruby, C#, Rust y PHP, además de un proveedor de Terraform y una CLI que puedes ejecutar directamente desde npm.
- Payloads firmados. Claves simétricas precompartidas por defecto; el README sitúa la firma simétrica en torno a 50 veces más rápida de firmar y 160 veces más rápida de verificar que la opción asimétrica ed25519, que también está soportada para cuando prefieras repartir una clave pública en vez de un secreto.
- Reintentos y cola de mensajes fallidos. Los errores internos repetidos acaban dejando una tarea en una DLQ, y el README te dice que vigiles su profundidad con una métrica dedicada y que la reproceses desde un endpoint de administración una vez arreglada la causa.
- Protección contra SSRF. Los envíos a direcciones IP internas están bloqueados por defecto, con una lista de subredes permitidas para el caso en que el receptor sea realmente interno.
- Webhooks operativos. El servidor puede enviarte webhooks sobre sí mismo, así te enteras de que un cliente desactivó o cambió un endpoint sin tener que consultarlo periódicamente.
El README es inusualmente franco sobre sus propios límites: el servicio alojado tiene funcionalidades, optimizaciones y comportamientos que todavía no están en el repositorio, y describe ambos como mayormente compatibles pero no del todo. Merece la pena leerlo antes de dar por hecha la paridad con la versión de código abierto.
Por qué los webhooks son una superficie de crecimiento y no solo fontanería
Los webhooks se archivan como tema de ingeniería, y por eso siempre son del próximo trimestre. Ese archivado es un error. Un webhook saliente es la única integración que construyes una vez y no vuelves a construir: cuando existe, tus clientes te conectan a Zapier, a n8n, a sus scripts internos y a lo que ya usen, y cada uno de esos es un acuerdo que no tuviste que negociar. Nuestra página sobre si merece la pena construir integraciones desarrolla el argumento completo; los webhooks son la fila más barata de esa tabla.
- Distribución sin acuerdos Un solo endpoint te mete dentro de todas las herramientas de automatización que tus clientes ya pagan, sin publicar un conector para ninguna.
- Retención que no tuviste que defender Un cliente cuyo sistema interno reacciona a tus eventos tiene un coste de cambio que ninguna tabla comparativa crea.
- Un soporte más barato "¿Por qué no se disparó?" se responde desde un registro de entrega que el cliente puede ver, y no desde tus propios logs a las once de la noche.
- Una razón para escribir documentación que la gente lee Los payloads de eventos son de las pocas páginas de documentación que se guardan en marcadores, lo que las convierte en muy buenas candidatas a posicionar.
Lo que nos enseñó estar en el lado receptor
Nosotros no enviamos webhooks a gran escala; consumimos muchos, para pagos, para chat y para cada integración que tocan nuestros agentes. De ahí salieron dos hábitos, y los dos son decisiones que también tomas en el lado emisor. Primero: un receptor debe responder 200 y registrar el evento incluso cuando la funcionalidad que lo consume está desactivada, porque cualquier otra cosa hace que el emisor reintente, y una tormenta de reintentos es peor que un evento que ignoras. Segundo: todo manejador tiene que poder ejecutarse dos veces sin daño, porque el mismo evento va a llegar dos veces. Eso no es un fallo del emisor: es lo que significa la entrega al menos una vez.
La imagen espejo en el lado emisor es lo que hicimos mal en otro sitio y no repetiríamos: un éxito de transporte no es un éxito de la acción. Una vez registramos un post como publicado porque la llamada HTTP devolvió 200, mientras el cuerpo de debajo decía que había sido rechazado. Si eres tú quien envía los webhooks, haz que el registro de entrega refleje lo que dijo el cuerpo del receptor y no lo que decía la línea de estado, y dale a tus clientes el historial para que puedan comprobarte. Publicar webhooks no trae a nadie por sí solo; anunciarlos a los clientes que los pedían, documentar los payloads y aparecer donde miran los usuarios de automatización es lo que sí trae. Esa mitad es el mismo trabajo de crecimiento que todo lo demás, y para eso está AgentCeres — the AI Growth Officer, en agentceres.com: los agentes redactan el anuncio, la página de documentación y el contacto, y una persona aprueba lo que sale.
FAQ
- ¿Es gratis autoalojar Svix?
- Sí. El repositorio tiene licencia MIT y el servidor arranca desde su propio Docker Compose con PostgreSQL, más Redis si quieres la cola y la caché sobre Redis. La misma empresa vende una versión alojada, y el README dice explícitamente que el despachador de código abierto no tiene todas las funcionalidades y optimizaciones del servicio alojado. Conviene contrastarlo con tus requisitos en lugar de suponer que son el mismo producto.
- ¿Necesito Redis de verdad?
- No necesariamente: el README lista PostgreSQL como obligatorio y Redis como opcional, para la cola de tareas y la caché. Si lo usas, hay dos notas de configuración del README fáciles de pasar por alto y caras de aprender: activa la persistencia para que las tareas encoladas sobrevivan a un reinicio, y ajusta la política de expulsión para que nunca se descarten claves sin caducidad explícita.
- ¿Firmas simétricas o asimétricas?
- La simétrica es la opción por defecto y la recomendada. Es muchísimo más rápida en ambos lados y bastante más simple de verificar para tus clientes, a cambio de un secreto compartido por endpoint. La firma asimétrica ed25519 existe para cuando prefieras publicar una clave pública en vez de repartir secretos, algo que importa sobre todo cuando tus receptores son terceros con los que no tienes relación de soporte.
- ¿No sería mejor construir el envío de webhooks yo mismo?
- Puedes, y la primera versión es pequeña. Lo que crece es todo lo de alrededor: retroceso exponencial, desactivar un endpoint tras fallos repetidos, protección contra reenvíos, rotación de secretos, un historial de entrega que tus clientes puedan leer y una cola que no pierda eventos cuando el proceso se reinicia. Es la misma forma de construir-o-comprar sobre la que escribimos en ¿construyo mi propio agente de marketing con IA?: el prototipo es un fin de semana, la mitad operativa no.
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.