Webhook

Un webhook es un mecanismo de integración por el cual una aplicación envía de forma automática una notificación HTTP a una URL definida por otra aplicación, justo en el momento en que ocurre un evento relevante (por ejemplo, se cierra una venta, se aprueba un pago o se entrega un pedido). En lugar de que el sistema receptor tenga que preguntar repetidamente "¿pasó algo nuevo?", es el sistema emisor el que avisa apenas pasa. Por eso a los webhooks se los suele describir como una "API inversa" o como devoluciones de llamada vía HTTP.

La pieza central es el endpoint receptor: una URL pública que escucha esos avisos y, al recibirlos, dispara una acción (guardar un registro, mandar un mensaje, actualizar un dato). Los webhooks son una de las formas más comunes de conectar herramientas de negocio entre sí, y son parte del trabajo de integración que coordinamos en proyectos sobre Salesforce cuando hay que enlazar el CRM con pasarelas de pago, plataformas de e-commerce o canales de mensajería.

Cómo funciona un webhook, paso a paso

El flujo de un webhook tiene siempre los mismos actores: un sistema que emite el aviso y un sistema que lo recibe. Primero, en el sistema emisor (digamos, una pasarela de pago) configurás una URL de destino y elegís qué eventos te interesan (pago aprobado, pago rechazado, reembolso). Cuando uno de esos eventos sucede, el emisor arma un mensaje, normalmente en formato JSON, con los datos del evento, y lo envía a tu URL mediante una petición HTTP POST. Tu endpoint recibe esa petición, lee el contenido (el payload) y ejecuta la lógica que vos definiste. Finalmente, tu sistema responde con un código de estado HTTP (idealmente un 200) para confirmar que recibió el aviso correctamente.

Ese "acuse de recibo" es clave: si tu endpoint no responde a tiempo o devuelve un error, la mayoría de los proveedores reintenta el envío más tarde, a veces durante horas. Por eso un endpoint bien hecho responde rápido (confirma la recepción) y procesa la tarea pesada después, en segundo plano.

Por qué importa para el negocio

La gran ventaja del webhook es que trabaja en tiempo real y de forma eficiente. La alternativa clásica es el polling: tu sistema le pregunta al otro cada pocos minutos "¿hay algo nuevo?". El polling desperdicia recursos (la mayoría de las consultas vuelven vacías) e introduce demora (te enterás recién en la próxima consulta). El webhook invierte la lógica: no preguntás nada, te avisan apenas hay novedad. Para una empresa esto significa procesos que reaccionan al instante: un cliente paga y el pedido se libera solo, un lead completa un formulario y entra al CRM en el momento, un envío se entrega y el cliente recibe la notificación sin intervención humana.

Webhook vs API: en qué se diferencian

Webhook y API suelen confundirse porque ambos conectan sistemas, pero la diferencia es la dirección y el disparador:

En la práctica se complementan: un webhook te avisa que algo pasó, y muchas veces tu sistema responde llamando a la API del proveedor para traer el detalle completo del registro.

Ejemplo concreto en Argentina

Pensá en un e-commerce que cobra con Mercado Pago e integra su CRM sobre Salesforce. Cuando un comprador paga, Mercado Pago dispara un webhook hacia el endpoint de la tienda. Ese aviso desencadena en segundos: se marca la orden como pagada, se descuenta el stock, se genera la factura electrónica y se manda un WhatsApp de confirmación al cliente. Sin webhooks, el equipo tendría que revisar el panel de pagos a mano o programar consultas periódicas, con la consecuente demora y el riesgo de error. Lo mismo aplica a Calendly avisando de una reunión agendada, a una plataforma de firma electrónica confirmando un documento firmado, o a un sistema logístico notificando una entrega.

Errores y cuidados comunes

• No validar el origen. Como tu URL es pública, cualquiera podría enviarle datos falsos. Los buenos proveedores firman cada envío (por ejemplo, con una firma HMAC en un encabezado) para que verifiques que el aviso vino realmente de ellos.
• No manejar reintentos ni duplicados. Un mismo evento puede llegar más de una vez. El endpoint debería ser idempotente: procesar dos veces el mismo aviso no debe duplicar la orden ni el cobro.
• Procesar todo en línea. Si tu endpoint tarda mucho, el proveedor lo considera caído y reintenta. Conviene responder rápido y delegar el trabajo pesado a una cola.
• Confiar en el orden de llegada. Los eventos no siempre llegan en secuencia; tu lógica debería tolerar que un "pedido entregado" aparezca antes que un "pedido despachado".

En proyectos de integración, los webhooks suelen combinarse con plataformas de tipo iPaaS o middleware, que reciben el aviso, lo transforman y lo encaminan al sistema correcto, agregando seguridad, reintentos y trazabilidad sin que haya que programar todo desde cero.