Índice del artículo
En 30 segundos
Un webhook es un aviso automático que un programa envía a otro cuando ocurre algo, como un pedido o un pago, para que pueda reaccionar.
La pregunta útil para tu negocio es qué ocurre después: quién recibe los datos, qué trabajo se pone en marcha y qué decisión queda en manos de una persona.
El timbre de tu negocio
Piensa en el timbre de un comercio. Cuando llega alguien, suena y quien está dentro puede atender. No hace falta asomarse continuamente a la puerta. Entre programas ocurre algo parecido: el que conoce el hecho manda el aviso a una dirección web preparada para recibirlo. El programa receptor es el que atiende esa dirección. El evento, como lo llama la documentación, es simplemente el hecho que provoca el aviso.
Ejemplos ilustrativos de pymes: un restaurante de Zaragoza recibe pedidos en su propia web. Su proveedor prepara una conexión para enviar a Make, una herramienta que conecta aplicaciones, el identificador del pedido, los platos y la hora solicitada. El identificador permite distinguir ese pedido de los demás. Configura el recorrido para registrar el pedido como pendiente y avisar al equipo. Después, una persona confirma la capacidad de cocina, la hora de recogida y la aceptación final.
Quién avisa a quién
- Pedido en la web
- La web avisa
- Recibe y comprueba
- Registra pendiente
- El equipo decide
La flecha del webhook va del emisor al receptor: del programa que conoce la novedad al que debe recibirla. Ese papel depende de qué aplicación estés mirando. En el ejemplo, la web del restaurante envía y Make recibe; la cocina interviene después, según el trabajo que haya preparado el proveedor.
No lo confundas con
API
Una API permite a un programa consultar datos o pedir acciones a otro. Con el webhook, el emisor avisa. Ese aviso puede llevar al receptor a consultar la API para completar la información.
Automatización
La automatización es el trabajo completo que sigue unas reglas. El webhook puede iniciarlo; después vienen las comprobaciones y las acciones que alguien haya configurado. Un flujo es esa secuencia de pasos.
Inteligencia artificial
Recibir un aviso no requiere IA. El restaurante puede registrar la solicitud y avisar al equipo con reglas fijas. Incorporar inteligencia artificial sería una decisión distinta del diseño del proceso.
Recibir el aviso no significa terminar el trabajo
Una respuesta de aceptación confirma la recepción, no el resultado final. Make puede admitir el aviso en una cola: una lista de trabajos pendientes de procesar. Zapier también contempla retrasar el procesamiento aunque haya aceptado la entrada. Por eso, al revisar una conexión, pide ver el resultado en la aplicación de destino. Que el historial muestre un aviso recibido no basta para dar por tramitado el pedido o enviado el mensaje al equipo.
Una academia de Valencia quiere dar acceso a un curso tras un cobro con Stripe Checkout. La integración debe verificar el aviso, consultar la compra y comprobar el estado del pago antes de conceder el acceso previsto. Una página de agradecimiento no sustituye esa comprobación: el comprador puede pagar y no llegar a verla. Además, algunos métodos confirman el cobro después. La academia define las reglas de acceso y una persona resuelve las devoluciones y excepciones comerciales.
Qué pedir antes de dar la conexión por terminada
Comprobar quién envía
Pide una prueba de procedencia verificada: el sistema debe rechazar un aviso que no pueda autenticar. Autenticar significa comprobar que procede de quien dice enviarlo. Stripe utiliza una firma, una comprobación asociada al mensaje. n8n y Make permiten configurar otros mecanismos de autenticación. No son intercambiables por pegar la misma dirección: quien implanta la conexión debe comprobar que el emisor y el receptor admiten el método elegido. Ensaya el rechazo con datos ficticios antes de activar acciones reales.
Repetir el mismo aviso
Comprueba que un hecho produzca un solo efecto aunque llegue repetido. El proveedor debe guardar la identidad del evento y reconocer que ya se ha tratado. No basta con probar dos envíos seguidos: la solución debe soportar también que lleguen a la vez. En Stripe, la firma cambia entre intentos, por lo que no sirve como identidad del hecho. Para tu negocio, la comprobación es concreta: el mismo pedido no aparece duplicado y la misma compra no concede otro acceso.
Preparar la recuperación
Encarga una prueba con el receptor fuera de servicio y pide que te enseñen cómo se recupera lo pendiente. La política depende de quien manda el aviso: Stripe reintenta entregas fallidas; GitHub no las reenvía automáticamente. No des por hecho que lo resolverá el proveedor del programa. Acordad quién detecta el fallo, cómo consulta los intentos y cómo vuelve a poner el trabajo en marcha. El resultado de la prueba debe mostrar qué quedó pendiente y cómo se recuperó.
Cambiar el orden
Pide que el proceso pueda consultar el estado actual cuando los avisos lleguen desordenados. Stripe no asegura su orden de entrega. Si el receptor necesita saber cómo está una compra, puede consultar ese dato mediante la API en lugar de deducirlo solo de qué mensaje llegó antes. Quien lo implanta debe explicar qué dato manda cuando hay diferencias. Tú necesitas saber qué estado verá el equipo y qué ocurrirá si un aviso antiguo llega después de otro más reciente.
Asignar lo pendiente
Deja un responsable de los errores y una forma de ver el trabajo sin resolver. La prueba debe incluir un fallo después de recibir el aviso, no solo una entrega que no llega. Pide que se registre qué acción falta y quién recibe el aviso del problema. Así puedes distinguir una entrada aceptada de una tarea finalizada. El encargo termina cuando hay una forma de localizar y atender esas excepciones; no cuando el dibujo del flujo parece completo.
Por dónde seguir
Si estás decidiendo cómo conectar tus aplicaciones, empieza por distinguir aviso y consulta. La comparación Webhook y API desarrolla esa diferencia; qué es una API amplía la pieza que permite consultar o pedir acciones. Para entender cómo encaja el aviso en un proceso entero, sigue con qué es una automatización. No necesitas elegir una herramienta antes de tener claro qué programa avisa y qué respuesta esperas.
Si ya puedes describir el recorrido, pasa a Webhooks en la práctica. Y si buscas ayuda para preparar la conexión, consulta el servicio de automatizaciones de Ciade. Lleva un encargo concreto: el hecho que inicia el trabajo, las aplicaciones implicadas, el resultado esperado y quién resuelve las excepciones. Es una base más útil para hablar con quien lo implante que pedir un webhook sin definir qué debe conseguir en tu negocio.
Dudas sobre webhooks, respuestas cortas
¿Cualquier programa puede enviar webhooks?
El emisor debe admitirlos o hay que preparar esa función en una aplicación propia. Crear una dirección receptora en Make no añade esa capacidad a cualquier programa externo. Si tu aplicación no ofrece avisos, puede hacer falta consultar periódicamente sus datos mediante una conexión que permita hacerlo.
¿Un webhook sustituye a una API?
El aviso y la consulta se complementan. El webhook informa de que ha ocurrido algo; una API permite consultar datos o pedir acciones a otro programa. Tras recibir el aviso, el receptor puede necesitar consultar el estado actual de la compra antes de decidir qué hacer.
¿Recibir el aviso significa que el pedido está tramitado?
Recibido no significa terminado. El receptor puede aceptar el aviso y dejar el trabajo pendiente en una cola. Comprueba el resultado en la aplicación de destino: que el pedido esté registrado o que el equipo haya recibido el mensaje. Deja también un responsable de las acciones que fallen.
¿Qué pasa si el aviso se repite o no llega?
La conexión debe prever ambos casos. Pide que el mismo hecho produzca un solo efecto aunque llegue repetido, incluso a la vez. Para recuperar avisos fallidos, comprueba las reglas del emisor: Stripe reintenta las entregas; GitHub no las reenvía automáticamente. Acuerda quién detecta el fallo y recupera lo pendiente.
Fuentes
Fuentes oficiales, consultadas el 4 de noviembre de 2026
- GitHub · Qué es un webhook y cómo se diferencia de consultar
- Stripe · Recepción de eventos y avisos repetidos
- Stripe · Firmas, receptores y recuperación de eventos
- Stripe · Entregar un servicio tras comprobar el pago
- Stripe · Disponibilidad en España
- GitHub · Recuperar entregas fallidas
- n8n · Receptor y direcciones de prueba y producción
- Make · Recepción, colas y trabajo posterior
- Make · Configuración y autenticación del receptor
- Zapier · Límites y retrasos de procesamiento
- Stripe · Reintentos, orden y consulta del estado actual
Cómo lo comprobamos. Documentación oficial consultada el 4 de noviembre de 2026. Ciade no ha probado las conexiones descritas. Los ejemplos no corresponden a clientes de Ciade ni cuentan con resultados medidos.
Qué ha cambiado.
- 4 de noviembre de 2026: Reescritura v2: definición, recorrido visual, diferencias con API y automatización, pruebas de entrega y dudas frecuentes.
Términos relacionados
Aprende a usar la IA en tu trabajo, con criterio.
El nivel 0 es gratis: cuarenta minutos para entender qué pedirle a la IA y qué revisar. El programa completo enseña a implementarla en tu propio negocio, tarea a tarea.
