HTTP 200 no significa que tu automatización funcionó
Cuatro proveedores distintos —facturación, WhatsApp, integraciones, gobierno— con el mismo patrón: una respuesta exitosa que oculta un fallo real.
El error más caro no es un fallo, es un falso éxito
Un flujo que se cae es fácil de detectar: hay una alerta, un log rojo, alguien revisa. El problema real aparece cuando un proveedor externo responde "todo salió bien" y no es cierto. Nadie investiga un proceso que dice haber funcionado, así que el error se descubre semanas después —en un cierre contable, en un cliente que nunca recibió su mensaje, en una factura que legalmente no existe— cuando ya es mucho más caro de corregir.
Llevamos varios agentes de IA en producción para empresas colombianas, integrados con facturación electrónica, WhatsApp, CRMs y APIs de gobierno. En cuatro proveedores completamente distintos encontramos exactamente el mismo patrón, documentado de forma independiente cada vez: la respuesta técnica dice éxito, el resultado de negocio dice otra cosa.
Cuatro proveedores, el mismo patrón
Facturación electrónica DIAN. Una integración con la API de un proveedor de facturación llamaba al endpoint de creación de factura, recibía 200/201 y marcaba la operación como exitosa. Lo que ese endpoint hace en realidad es crear un borrador. El timbrado ante la DIAN —el paso que le da validez legal al documento— es una llamada aparte, asíncrona, con su propio estado de "Accepted" que hay que consultar por separado. Durante un tiempo, el sistema reportó como facturadas operaciones que legalmente no existían.
Integraciones de terceros (Composio y similares). Varias plataformas de integración devuelven {"successful": true} incluso cuando la operación real falló con un error 500 interno, anidado dentro del payload de respuesta. Si tu código solo revisa el flag successful, nunca te enteras. Hay que bajar un nivel y revisar el código de estado real dentro de la respuesta.
WhatsApp Cloud API. Enviar una imagen en formato .webp a través de la API de WhatsApp devuelve 200 OK. Meta la acepta, la encola, y después la descarta de forma asíncrona porque solo JPEG y PNG son válidos para mensajes de tipo imagen. El remitente nunca ve un error — el mensaje simplemente no llega, y el 200 inicial ya generó una falsa sensación de que todo estaba bien.
Páginas de entidades públicas. Un proceso de scraping contra un dominio gubernamental colombiano recibía 200 OK en cada intento. El contenido real era una página de bloqueo de un bot manager (Radware), no la información buscada. Sin verificar el contenido real de la respuesta, el proceso "funcionó" durante días sin extraer un solo dato útil.
Cómo lo resolvemos: verificar el recurso, no la respuesta
La regla que aplicamos ahora en cada integración nueva es simple de enunciar y fácil de saltarse si no se automatiza: nunca marcar una operación como exitosa solo porque el código de estado HTTP fue 2xx.
En la práctica significa cosas concretas. Para SIIGO, encadenar la creación del borrador con un polling activo hasta que el estado sea "Accepted", no "Draft". Para integraciones tipo Composio, chequear explícitamente el código de estado dentro del payload (status.code >= 400), nunca confiar en el flag successful. Para WhatsApp, validar el formato del archivo antes de enviarlo —no después— y verificar el estado de entrega real en vez de asumir que un 200 en el envío implica recepción. Para scraping contra fuentes no controladas, comparar el contenido esperado contra el recibido, no solo el código de estado.
Ninguna de estas verificaciones es exótica. Son controles baratos de implementar y carísimos de omitir. La diferencia entre una automatización que "corre" y una automatización en la que una empresa puede confiar su facturación o su atención al cliente está casi siempre en este tipo de detalle, no en qué tan sofisticado es el modelo de lenguaje que usa por detrás.