HTTP 200 y resultado de negocio: qué debe verificar un agente

La respuesta técnica y el resultado de negocio

Una respuesta HTTP aporta evidencia sobre una petición. Para saber si una tarea empresarial terminó, también hay que conocer el contrato de la API y comprobar el estado del recurso esperado. El RFC 9110 define la semántica HTTP; no establece el criterio de aprobación de una factura, una cita o una entrega comercial.

El título expresa una precaución práctica: no convertir una señal técnica aislada en una afirmación que el usuario entienda como resultado final. Hay API cuya respuesta confirma una creación y otras que sólo reciben trabajo para procesarlo después. Hay que leer la operación concreta.

Define qué significa terminar

Para una solicitud de reunión, el criterio podría ser un evento confirmado con identificador y horario; para un documento, un registro consultable en el estado acordado. La aceptación de un correo por un proveedor tampoco demuestra que la persona lo haya leído.

Antes de programar, escribe tres estados: recibido, procesado y confirmado. Añade pendiente cuando falta una comprobación y fallido cuando existe evidencia del error. Si la tarea requiere aprobación humana, conserva ese estado por separado.

Un informe pendiente

Datos de prueba. Un servicio responde que recibió un archivo y devuelve un identificador de trabajo. El agente muestra “Archivo recibido; informe pendiente”. Después consulta el resultado y verifica período, número de registros y errores. Sólo entonces presenta el informe como preparado.

Si la consulta falla, no debe inventar un resultado ni repetir ciegamente la carga. Conserva el identificador y ofrece reintentar la comprobación o solicitar ayuda. No se deben atribuir fallos a un proveedor sin evidencia.

Comprobaciones que conviene guardar

• Identificador interno y referencia externa de la operación, sin secretos en los registros.
• Estado del recurso y momento de la última comprobación.
• Campos mínimos esperados según el contrato.
• Motivo de rechazo o información faltante.
• Responsable y procedimiento para resolver una respuesta incierta.

El tratamiento de errores de un orquestador, como el descrito por n8n, ayuda a encaminar fallos. Aun así, el flujo debe comprobar los estados del servicio que realiza la tarea.

Cómo probar sin afirmar más de lo observado

Incluye respuestas incompletas, demoras, errores de autenticación, duplicados y pérdida de conexión después de una creación. Distingue los resultados locales de los comprobados contra la cuenta y el entorno autorizados. Una prueba local de formato no acredita una integración real.

En automatización de procesos definimos la entrada, la acción, la revisión y la evidencia de salida de cada tarea. Puedes describir tu recorrido para evaluar qué confirmaciones necesita.