Integraciones # APIs asíncronas: cómo reintentar sin duplicar trabajo Una conexión puede interrumpirse aunque el trabajo haya empezado. Diseñar alrededor de la operación permite recuperar el resultado con claridad. Por ApiNitro · 14 de septiembre de 2026 ## Una respuesta inicial no siempre es el resultado Cuando una consulta depende de una fuente externa, mantener abierta una conexión no garantiza una buena experiencia. Un flujo asíncrono permite aceptar el trabajo y recuperar su resultado después. En HTTP, una respuesta 202 indica aceptación para procesamiento; no demuestra que el trabajo haya terminado con éxito. La aplicación necesita representar esa diferencia. Podés mostrar que la solicitud fue recibida, conservar su identificador y permitir que la persona continúe. «Procesando» debe convertirse en resultado o en un estado de fallo claro, sin exigir que el navegador permanezca abierto. ## El reintento pertenece a la misma operación Imaginá que enviás una consulta y perdés la conexión antes de leer la respuesta. Crear otra solicitud sin contexto puede repetir trabajo ya aceptado. La idempotencia permite relacionar esos intentos con una misma intención, según el contrato de la API. La identidad del intento debe persistirse antes del envío y reutilizarse si la red falla. Si cambian los parámetros o la intención, corresponde una operación nueva. Tampoco conviene deduplicar sólo porque dos consultas tienen datos iguales: una comprobación realizada más tarde puede ser una decisión nueva y válida del usuario. ## Un webhook avisa; tu aplicación decide El webhook permite recibir una notificación sin consultar el estado continuamente. El receptor debe comprobar su autenticidad de acuerdo con la documentación de integración y registrar la entrega antes de activar acciones de negocio. Un mensaje recibido dos veces no debería disparar dos veces el mismo proceso. Separar recepción y procesamiento ayuda a recuperar fallos. Por ejemplo, tu sistema puede guardar el aviso y luego actualizar una tarea interna. También conviene conservar un camino para recuperar el resultado autorizado cuando una notificación llega tarde o no puede entregarse. ## Diseñar la recuperación desde el principio Los reintentos necesitan pausas y un presupuesto, no un bucle inmediato. Ante una interrupción, la pregunta útil es si podés recuperar la operación existente antes de crear otra. Conservá la relación entre solicitud, operación y resultado para investigar el recorrido sin depender de mensajes informales. La interfaz puede distinguir una consulta pendiente, una fuente que no respondió y una entrega de notificación fallida. Son situaciones diferentes. Una notificación fallida no implica necesariamente que el resultado se haya perdido, ni debería convertir un trabajo terminado en una consulta nueva. ## Aplicaciones y agentes comparten la responsabilidad Un cliente REST y un agente conectado mediante MCP pueden iniciar el mismo tipo de trabajo desde experiencias diferentes. Ambos necesitan autorización, seguimiento y una política explícita de reintentos. Reconectar un cliente no debería borrar el contexto de una operación en curso. Antes de integrar, probá desconexiones después del envío, avisos duplicados y resultados demorados. Verificá qué ve el usuario y qué acciones ejecuta tu sistema en cada caso. El objetivo es recuperar la intención original sin producir trabajo adicional por accidente. ## Fuentes y lecturas - [MDN: 202 Accepted ↗](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/202) - [Amazon Builders' Library: Making retries safe with idempotent APIs ↗](https://aws.amazon.com/builders-library/making-retries-safe-with-idempotent-APIs/) [← Todos los artículos](https://apinitro.com/articulos/)