Un 200 no prueba que tu integración funciona

El 20 de agosto de 2026 auditamos nuestro propio sitio y encontramos que uno de nuestros webhooks aceptaba peticiones de cualquiera.

No estaba caído. No daba error. Respondía 200 OK, que es exactamente lo que uno quiere ver.

Qué había pasado

El endpoint recibe eventos de Meta y, antes de hacer nada con ellos, tiene que comprobar la firma que Meta envía: es lo que demuestra que el mensaje viene de Meta y no de alguien que descubrió la URL.

Esa comprobación estaba escrita más o menos así:

si existe APP_SECRET:
    verificar la firma
    si no coincide: rechazar
procesar el evento

Lee la condición otra vez. Si la variable no está configurada, no se verifica nada y el evento se procesa igual. El código no falla, no avisa, no deja rastro. Simplemente se salta la única puerta que tenía.

Se le llama fail-open: ante la duda, abrir. Es la decisión contraria a la que uno querría, y casi siempre aparece sin que nadie la haya tomado a propósito — sale de escribir la validación como algo opcional en lugar de como un requisito.

Lo comprobamos en producción mandando una petición sin firma. Respondió 200.

Lo que lo hace peligroso no es el fallo, es el silencio

Un servicio caído se nota. Alguien llama, el gráfico baja, salta una alerta.

Esto no. Durante todo el tiempo que estuvo abierto:

• Ninguna alerta se disparó. No había nada anómalo que detectar: las peticiones entraban y se procesaban.
• Ningún log lo delataba. Un log registra lo que pasa, no lo que debería haber pasado y no pasó.
• Los tableros se veían perfectos. Peticiones recibidas, respuestas 200, cero errores.

La métrica que mirábamos —tasa de respuestas correctas— estaba en verde precisamente porque el problema existía. Un sistema que rechaza lo que debe rechazar muestra errores; el nuestro no mostraba ninguno.

Se corrigió el mismo día invirtiendo la condición: sin la variable configurada, el endpoint responde 401 y no procesa nada. Ahora, si alguien despliega sin esa variable, el webhook deja de funcionar de forma ruidosa. Es mejor que funcione mal de una manera que se note.

El mismo principio, en otro sitio

Este patrón no vive solo en los webhooks. El caso que más veces encontramos en cuentas ajenas es el de los mensajes automáticos de WhatsApp.

Cuando un cliente te escribe se abre una ventana de 24 horas. Pasada esa ventana, solo puedes contactarlo con una plantilla aprobada por Meta. Si tu automatización manda un mensaje normal a los tres días, ocurre lo siguiente: la API acepta la petición, devuelve éxito, y el mensaje nunca se entrega.

Nadie se entera. El sistema registra que envió el seguimiento. El reporte dice que la campaña de reactivación salió. Y el cliente nunca recibió nada.

Es el mismo error de fondo: confundir "el sistema aceptó mi petición" con "lo que yo quería que pasara, pasó". Son dos cosas distintas, y solo una le importa al negocio. Si estás montando automatizaciones sobre WhatsApp, la API oficial y sus reglas son lo primero que hay que entender bien.

Qué mirar en su lugar

No hace falta un sistema de monitoreo caro. Hace falta cambiar la pregunta: en vez de ¿respondió bien?, preguntar ¿ocurrió lo que tenía que ocurrir?

Verifica el efecto, no la respuesta. Si el webhook debía crear un contacto en el CRM, la comprobación es buscar ese contacto por API y ver que existe con los campos correctos. Si debía mandar un mensaje, es mirar la conversación. El código de respuesta te dice que la petición llegó, no que sirvió de algo.

Prueba los casos que deben fallar. Casi todo el mundo prueba que lo correcto funciona. Casi nadie prueba que lo incorrecto se rechaza. Manda una petición sin firma, con una firma inválida, con datos incompletos — y comprueba que cada una recibe el rechazo que le toca. Nuestro fallo llevaba meses ahí porque la prueba que lo detecta nunca se había hecho.

Que lo mal configurado se rompa a lo grande. Una integración a la que le falta una variable de entorno debería negarse a arrancar. Si en su lugar sigue adelante con la validación desactivada, has cambiado un fallo visible por uno invisible, que es peor.

Desconfía del verde permanente. Un panel donde todo lleva meses en verde no siempre significa que nada falla; a veces significa que nada está mirando. Pregúntate qué tendría que ocurrir para que esa métrica se pusiera en rojo. Si no encuentras la respuesta, la métrica no está midiendo nada.

Por qué contamos esto

Porque el hallazgo es nuestro y lo encontramos nosotros, auditando nuestro propio sitio en vez de esperar a que lo hiciera otro. Es la segunda vez este mes: el formulario de contacto también tenía lo suyo.

Si tienes integraciones corriendo —un formulario que entra al CRM, un bot que responde, campañas que reportan conversiones— vale la pena hacerse la misma pregunta. No ¿está funcionando?, sino ¿cómo lo sé?

Casi siempre, la respuesta honesta es que nadie lo ha comprobado desde el día que se instaló.