Cómo explicar una espera por límites de API sin ocultar un bloqueo

A las 9:10, la encargada de despachos abre el informe de existencias de la mañana. En pantalla siguen las cifras de ayer y el botón de actualización indica «Procesando». ¿Conviene esperar, avisar a soporte o enviar el informe aclarando la fecha de los datos? La respuesta depende de si el sistema tiene previsto otro intento.

Explicar por qué se espera y hasta cuándo

Imaginemos que el sistema consulta las existencias de un proveedor. Una respuesta HTTP 429 indica que el proveedor ha limitado la frecuencia de las solicitudes. Puede incluir una cabecera Retry-After con una espera en segundos o una fecha. Ese dato ayuda a programar otra consulta. Las cifras visibles siguen correspondiendo a la última importación correcta. Véanse RFC 6585, sección 4 y RFC 9110, sección 10.2.3.

Supongamos que la respuesta llega a las 09:10 e indica una espera de 120 segundos. Una vez guardado el intento para las 09:12, la pantalla puede mostrar «El proveedor ha pedido una pausa. Próxima consulta a las 09:12, hora de Nueva York. Existencias actualizadas por última vez ayer a las 17:40». Si el proveedor omite la cabecera, aplica la espera acordada por tu equipo e indica que el sistema eligió esa hora.

Acordar cuándo interviene una persona

En este ejemplo, despachos necesita tomar una decisión antes de las 09:20. Acuerda con operaciones un máximo de intentos y una hora límite. Si la siguiente consulta permitida cae después del límite, detén los intentos automáticos y deriva el informe a la persona responsable del inventario. Mantén visible la fecha de las últimas cifras válidas. Facilita la referencia del informe, el historial de intentos y un lugar donde dejar constancia de la decisión de esperar datos recientes o enviar el informe anterior con su fecha.

Probar una espera normal y una tarea detenida

• En espera. Simula un proveedor que devuelve 429. Comprueba que al recargar la página se conserva la hora programada y que el proveedor no recibe otra consulta.
• Con retraso. Pausa el proceso de prueba hasta que pase la hora del siguiente intento. Verifica que la pantalla señala el retraso y que soporte recibe la referencia del informe. Un contador que vuelve a empezar cada vez que se abre la página ocultaría el fallo.
• Recuperada. Permite que el proceso reciba una respuesta válida. Conserva la fecha anterior de actualización hasta que las nuevas cifras estén guardadas y disponibles para despachos.
• Detenida. Simula otra espera que supere la hora límite. Comprueba que cesan los reintentos automáticos, que la persona responsable ve el motivo y que volver a abrir el informe no inicia otra tarea.

Pide a la encargada que lea cada pantalla y diga qué cifras puede usar, cuándo conviene volver a consultar y a quién corresponde actuar. Si para responder necesita abrir un registro del servidor, revisa el mensaje antes de dar por bueno el proceso.

Contacta con Dynelink para definir los estados de espera y las pruebas de aceptación de una integración con proveedores.

Ilustración conceptual generada con IA; no es una captura de un cliente.