# Que é un webhook e para que serve na práctica Source: https://baqueiro.es/gl/codigo-que-trabaja-por-ti/que-e-un-webhook-e-para-que-serve/ Published: 2025-04-23T06:56:00+00:00 Updated: 2025-04-23T06:56:00+00:00 Author: Baqueiro Desarrollo Web Language: gl-ES Usage: Atribución requirida: permítese a cita cunha ligazón visible de volta --- **TL;DR** - Un webhook é un aviso automático que un sistema lle envía a outro cando ocorre un evento concreto. É a diferenza entre preguntar sen parar “pasou algo?” e recibir unha chamada cando pasa. - É o mecanismo que hai detrás da maioría das automatizacións entre aplicacións: un pagamento completado en Stripe, un pedido novo en WooCommerce, un usuario que se rexistra na túa plataforma. - Entendelo axúdache a avaliar con criterio as propostas de integración e a facer as preguntas correctas aos teus provedores técnicos. Nalgún momento dunha reunión sobre integración de sistemas ou automatización de procesos, alguén di a palabra webhook. E hai 2 reaccións: a do técnico, que asente porque sabe de que se fala, e a da directora de operacións ou o responsable de negocio, que tamén asente, pero sen ter de todo claro que é un webhook nin por que importa. Este artigo é para o segundo perfil. Non explica como se programa un webhook. Explica que é, que problema resolve e por que aparece en calquera conversa seria sobre integración de aplicacións. ## A diferenza entre unha API e un webhook Para entender un webhook axuda comparalo cunha API, que é o concepto máis coñecido. Se non o tes claro, podes ler antes [que é unha API e por que debería importarche](https://baqueiro.es/gl/codigo-que-trabaja-por-ti/que-e-unha-api-e-por-que-che-importa/). Unha API funciona cun esquema de pregunta e resposta: o teu sistema pregunta e o sistema externo responde. Para saber se hai pedidos novos, o teu sistema ten que preguntarlle á tenda cada certo tempo: “hai pedidos novos?”. Se os hai, recíbeos. Se non, recibe unha resposta baleira e volve preguntar máis tarde. É como chamar a alguén cada 10 minutos para ver se ten novas para ti. Un webhook inverte esa lóxica: en lugar de que o teu sistema pregunte, o sistema externo avísate cando algo ocorre. A tenda ten configurado un webhook que di “cando chegue un pedido novo, envía os datos a este enderezo”. Cando entra o pedido, o aviso chega só. É como darlle a alguén o teu número para que te chame cando teña novas. Na práctica, os webhooks son máis eficientes, porque non hai consultas inútiles cando non pasa nada, e máis inmediatos, porque o aviso chega no momento do evento e non na seguinte rolda de consultas. Unha precisión para non liarse nas reunións: o webhook non substitúe a API, compleméntaa. O habitual é que o webhook avise de que algo pasou e que, se fai falta máis información, o teu sistema a pida despois a través da API. ## Como funciona un webhook na práctica Un webhook funciona en 3 pasos: **Paso 1: configuración.** No sistema que vai enviar o aviso (unha pasarela de pagamento, unha tenda en liña, un CRM) defínense 2 cousas: o evento que o dispara e o enderezo (URL) ao que se enviará. Por exemplo: “cando se complete un pagamento, enviar os datos a https://tusistema.com/webhook/pagos”. **Paso 2: o evento ocorre.** Cando o cliente completa o pagamento, o sistema envía automaticamente unha mensaxe HTTP a ese enderezo cos datos do evento: o identificador do pedido, o importe, os datos do cliente e o estado da transacción. **Paso 3: o teu sistema recibe e procesa.** O sistema que escoita nese enderezo recibe os datos e fai o que corresponda: actualizar o estado do pedido, enviar un correo de confirmación, avisar o almacén ou rexistrar o cobramento na contabilidade. Todo isto ocorre en segundos, de forma automática e sen intervención humana. Un detalle que separa unha implantación sólida dunha fráxil: o receptor debe confirmar axiña que recibiu o aviso e facer o traballo pesado despois. Se tarda demasiado en contestar, o emisor pode dar o envío por fallido e repetilo, e entón o mesmo evento chega 2 veces. ## Exemplos habituais de uso de webhooks ### Pagamentos e transaccións Stripe e PayPal usan webhooks para notificar eventos de pagamento, e Redsys fai algo equivalente coa súa notificación en liña ao comercio. Cando un cliente paga, o aviso pon en marcha o que vén despois: xerar a factura, enviar a confirmación, actualizar o inventario ou activar o acceso nunha plataforma de subscrición. Sen webhook, habería que consultar periodicamente o estado de cada transacción ou revisalo a man. ### Formularios e leads Cando alguén enche un formulario de contacto en WordPress, un webhook (propio do plugin de formularios ou mediante un complemento) pode enviar eses datos ao instante a un CRM: crear o contacto, asignalo ao comercial que corresponda segundo o tipo de consulta e activar unha secuencia de correos de benvida. Todo no momento en que se preme “enviar”. ### Xestión de inventario Se a tenda en liña e o sistema de xestión do almacén están conectados con webhooks, cando o stock dun produto baixa dun mínimo, o aviso xera automaticamente unha orde de reposición. Sen webhook, alguén ten que revisar o stock a man ou agardar a que a próxima sincronización detecte o cambio. ### Notificacións internas Os webhooks tamén serven para a comunicación interna. Cando se rexistra un cliente novo na túa plataforma, un webhook pode enviar unha mensaxe a unha canle de Slack do equipo comercial cos seus datos. Cando se produce un erro crítico en produción, pode alertar o equipo técnico de inmediato, sen que ninguén teña que estar vixiando unha pantalla. ## Por que importa entender os webhooks se non es técnico As integracións entre sistemas aparecen en case todas as propostas de desenvolvemento e en calquera conversa sobre automatizar procesos. Entender a diferenza entre unha integración baseada en consultas periódicas e unha baseada en webhooks permíteche facer mellores preguntas. “A integración usa webhooks ou consultas periódicas?” non é unha pregunta técnica: é unha pregunta sobre o actualizados que estarán os teus datos e o eficiente que será o sistema. Unha integración que consulta cada 10 minutos pode abondar en moitos casos. Noutros, como confirmacións de pagamento, alertas de stock ou avisos críticos, eses 10 minutos teñen un impacto real na operativa. Se queres pensar que procesos da túa empresa merecen este tipo de conexión, pódeche servir ler [que datos do teu negocio deberían actualizarse sós](https://baqueiro.es/gl/automatizacion/datos-negocio-actualizarse-sos/). ## Lista de verificación: preguntas sobre webhooks nunha proposta de integración - A integración proposta usa webhooks ou consultas periódicas a unha API? - Canto tardan os datos en pasar dun sistema ao outro? - Que pasa se o webhook falla? Hai reintentos automáticos? - Que pasa se o mesmo aviso chega 2 veces? Evítase duplicar pedidos, cobramentos ou facturas? - Rexístranse os eventos recibidos para poder revisalos se algo sae mal? - O enderezo do webhook está protexido para evitar envíos fraudulentos? ## Preguntas frecuentes ### Os webhooks son seguros? Depende de como estean implantados. Un webhook mal protexido pode aceptar datos de calquera que coñeza o enderezo, non só do sistema autorizado. As boas implantacións verifican unha sinatura: o sistema emisor inclúe unha sinatura criptográfica en cada mensaxe e o receptor comproba que corresponde ao emisor autorizado antes de procesar nada. Stripe, por exemplo, asina todos os seus webhooks. ### Que pasa se o meu sistema non está dispoñible cando chega un webhook? Os emisores ben deseñados inclúen reintentos: se o receptor devolve un erro ou non responde, volven enviar o aviso varias veces, con intervalos cada vez máis longos. Stripe, por exemplo, reintenta os envíos fallidos durante un máximo de 3 días. Aínda así, en procesos críticos convén que o receptor sexa fiable e que exista unha conciliación periódica que recupere os eventos que se puidesen perder durante unha caída. ### Podo usar webhooks sen saber programar? Nalgúns casos, si. Ferramentas como Zapier ou Make poden recibir webhooks e procesalos sen código: creas un disparador de tipo webhook, obtés un enderezo e pégalo no sistema que queres conectar. Se o fas, deixa por escrito que escenario recibe cada aviso e quen o mantén, porque [o custo oculto das automatizacións mal documentadas](https://baqueiro.es/gl/automatizacion/custo-automatizacions-mal-documentadas/) aparece xusto cando algo falla. Para un receptor á medida que execute lóxica de negocio propia, como actualizar a túa base de datos ou lanzar procesos internos, precisas desenvolvemento. En Baqueiro implantamos webhooks e integracións entre sistemas con código propio cando a lóxica o require, sen depender de plataformas de automatización externas. Se tes procesos que deberían comunicarse sós e non o fan, [cóntanolo](https://baqueiro.es/gl/contacto/).