La prueba de una API ajena suele empezar por el proxy: la ruta saliente se configura rápido y sin complicaciones. Después llega un webhook del mismo proveedor —una devolución de llamada que avisa de que un pedido se pagó, de que un número recibió un SMS o de que una tarea terminó— y los datos simplemente no llegan. Veamos por qué el proxy no tiene nada que ver, de dónde sale el corte y cómo organizar la recepción de las devoluciones de llamada para que no dependa del canal saliente.

El proxy cambia la ruta saliente, no abre la entrada

Un servidor proxy se interpone entre tu cliente y la API remota solo en el tramo de salida: tú inicias la conexión y él sustituye la dirección de retorno y la IP desde la que se ve la petición. Todo lo que ocurre después es la respuesta a una conexión que tú ya abriste. Un webhook funciona al revés: el iniciador es el proveedor, no tú. Él abre una conexión nueva hacia la URL que registraste de antemano en el panel o en los parámetros de la petición, y esa conexión no tiene ninguna relación con el canal por el que hace poco consultaste su API.

De ahí la confusión típica: cambiaste el canal saliente y supusiste que ahora las devoluciones de llamada irían por otro lado. En realidad, la ruta de la petición entrante depende solo de a dónde apunta la URL del receptor y de si esa dirección es visible desde fuera, no de por dónde salen tus peticiones.

Por qué no llega la devolución de llamada

Un webhook perdido tiene pocas causas, y todas están del lado del receptor, no del emisor. La máquina está detrás del NAT de un router doméstico o de oficina sin un puerto redirigido: desde fuera, su dirección simplemente no existe. La dirección local de desarrollo no se resuelve desde internet en absoluto. La URL registrada apunta a un host interno visible solo desde la red corporativa. El certificado TLS está vencido o fue emitido para otro dominio, y el handshake se corta antes de transmitir el cuerpo de la petición. El servidor responde con un código distinto de 2xx: la mayoría de los proveedores dejan de reintentar la entrega tras varios intentos fallidos.

Un caso aparte es la allowlist del propio proveedor: la infraestructura cambió, nadie actualizó el registro y las llamadas se apagan en silencio, sin ningún error en la interfaz.

Cómo recibir correctamente las devoluciones de llamada

El receptor de devoluciones de llamada debe ser una dirección de acceso público, con el puerto abierto y un certificado TLS vigente: un dominio o una IP a la que el proveedor pueda llegar directamente, sin proxies ni túneles de tu lado. Este requisito no se cruza con el canal que uses para las peticiones salientes a esa misma API.

La arquitectura correcta de recepción separa dos tareas: confirmar la recepción rápido y procesar los datos con calma. A la entrada hay un manejador ligero que guarda el cuerpo crudo de la petición en una cola y responde 200 de inmediato, sin esperar a la lógica de negocio. El procesamiento se hace de forma asíncrona, desde la cola, en un proceso aparte. Esto protege de los timeouts del lado del proveedor: si el procesamiento útil tarda segundos y el límite de respuesta es una fracción de segundo, un esquema síncrono tarde o temprano empezará a perder eventos ante cualquier bajón.

Si no es posible tener una dirección pública —un entorno cerrado, un banco de pruebas, un entorno temporal sin dominio—, usa polling en lugar de push: la mayoría de estas API ofrecen un endpoint paralelo para consultar el estado o la lista de eventos. Consúltalo según un horario. El retraso en recibir el evento pasará de segundos al intervalo de consulta, pero el requisito de accesibilidad pública desaparece por completo.

Verificación de la entrega

La verificación se hace con dos registros independientes, no con uno solo. El primero es el historial de entregas en el panel del proveedor: ahí se ven los intentos, los códigos de respuesta y los tiempos. El segundo es el log de tu propio receptor: la prueba de que la petición llegó físicamente a tu código y no fue interceptada por un balanceador o un CDN que respondió 200 por su cuenta, sin pasar el cuerpo más adelante. Un estado «entregado» en una interfaz ajena sin el registro correspondiente en tu cola es señal de un corte en algún punto intermedio, no motivo para dar la integración por funcionando.

Conviene revisar también la firma: si el webhook está firmado con una clave HMAC y el secreto quedó obsoleto tras una rotación, el servidor rechazará en silencio eventos válidos por considerarlos falsos; desde fuera esto se ve como «no llega».

Dónde sí hace falta un proxy

Sigue siendo útil en el tramo de salida de este mismo conjunto. Si pasaste al polling en lugar de push, cada consulta es una petición saliente a la API, y puedes distribuirla como cualquier otro tráfico hacia un servidor ajeno: por geolocalización, por frecuencia, con rotación de dirección ante un rate limit. Otro escenario es comprobar lo que ve la propia plataforma desde el país que te interesa: si la devolución de llamada depende de una lógica del proveedor específica de cada región, es más cómodo verificarla desde la geolocalización adecuada y no desde la dirección de un centro de datos por defecto.

Preguntas frecuentes

¿Se pueden recibir webhooks a través de un servidor proxy?

El proveedor debe llegar directamente a tu receptor, y el canal que usas para las peticiones salientes no participa en esa cadena. Si necesitas ocultar la dirección real del servidor, delante de él se coloca un proxy inverso: es otro rol, no lo confundas con el proxy saliente para las peticiones de cliente a una API ajena.

¿Por qué en el panel del proveedor dice «entregado» pero no hay datos?

El estado «entregado» significa que el proveedor recibió una respuesta 2xx desde tu dirección; pudo responder un balanceador, un CDN u otro servicio del mismo dominio sin pasar el cuerpo a tu cola. Compara el log del proveedor con el de tu propio receptor y no te fíes solo del estado en una interfaz ajena.

¿Qué hacer si no es posible tener una dirección pública?

Pasa al polling: consulta el endpoint de estado según un horario en lugar de esperar una notificación push. El retraso en recibir el evento aumentará, pero el requisito de que la máquina sea accesible públicamente desaparece por completo.

Para la parte saliente del conjunto —consultar la API del proveedor o verificar la lógica desde el país que necesitas— sirve un canal dedicado o rotativo del catálogo de proxies. La configuración está en el artículo sobre la rotación de IP por API, y las métricas del canal, en el material cómo comprobar la calidad de un proxy.