Por Nicho Agencia Digital · Publicado el
1. Distingue un límite temporal de otros errores
HTTP 429 indica que se han enviado demasiadas solicitudes en un periodo determinado. La respuesta puede incluir Retry-After para señalar cuánto esperar. No conviertas cualquier fallo en «intentar otra vez»: un permiso insuficiente, una credencial inválida o un dato rechazado necesitan otra decisión.
Consulta la documentación del proveedor y el cuerpo del error antes de programar la recuperación. Registra el tipo de operación, hora, código y un identificador de seguimiento. No copies tokens ni datos personales al registro. Un aviso de cuota de gasto agotada puede requerir intervención y no se corrige esperando unos segundos.
2. Guarda la tarea antes de enviarla
Separa la solicitud del negocio del intento técnico. La tarea conserva su identificador, estado, fecha de creación, próximo intento permitido y vencimiento comercial. Cada envío es un intento asociado. Así puedes distinguir «pendiente», «en proceso», «confirmada», «resultado incierto» y «requiere revisión».
Para operaciones que cambian pedidos o crean registros, define cómo evitar duplicados. No inventes una clave de idempotencia si el proveedor no la admite: revisa su mecanismo documentado y la posibilidad de consultar el resultado antes de repetir. La guía de idempotencia y pedidos duplicados desarrolla ese problema complementario.
3. Respeta la espera y limita el presupuesto de reintentos
Si el proveedor indica una espera válida, no programes el siguiente envío antes de ese momento. Si no la indica, utiliza una política conservadora acordada con sus límites: esperas progresivas, variación entre tareas para evitar que todas despierten juntas y un máximo de intentos o tiempo total. Son decisiones de diseño, no una autorización para superar la cuota.
Coordina los trabajadores que usan la misma cuenta. Limitar cada proceso por separado no sirve si diez procesos consumen simultáneamente el mismo cupo. Cuando un SDK ya reintenta automáticamente, revisa su configuración para no multiplicar sin querer los intentos mediante otra capa.
4. Decide prioridades y vencimientos comerciales
Ejemplo ficticio, no caso de NICHO: una distribuidora sincroniza precios y confirma reservas mediante un mismo proveedor. Propone revisar reservas pendientes antes que una exportación histórica, pero mantiene una capacidad mínima para que esa exportación no quede detenida indefinidamente. La prioridad debe definirse antes del incidente, no depender de quién reclame primero.
Una reserva vencida no debe ejecutarse horas después como si siguiera vigente. Antes de reenviar, comprueba cancelaciones, versión del pedido y vigencia de la operación. Puedes enlazar esta revisión con la cancelación de tareas cuando cambia el pedido. La cola conserva evidencia del descarte y el motivo.
5. Prueba recuperación sin saturar el servicio real
Simula respuestas 429 en un entorno de prueba, incluyendo una espera indicada, ausencia de esa indicación y varios trabajadores concurrentes. Verifica que la tarea siga guardada, que no haya envíos anticipados y que el límite de intentos termine en revisión en lugar de un bucle infinito. Microsoft recomienda probar estos caminos con respuestas simuladas y revisar el comportamiento real del SDK.
Añade casos vecinos: reinicio del trabajador mientras esperaba, cancelación del pedido, respuesta tardía y conexión interrumpida después del envío. Ese último caso puede dejar un resultado incierto; consulta el estado cuando sea posible antes de repetir una escritura. No hagas pruebas de saturación sobre una API ajena sin permiso.
6. Mide la cola, no solo la cantidad de errores
Observa tareas pendientes por antigüedad, tiempo hasta confirmación, vencimientos, intentos por tarea y cantidad que llega a revisión. Muestra por separado una operación confirmada y una solicitud simplemente enviada. El número de respuestas 429 por sí solo no permite saber cuántos pedidos se completaron.
Asigna una persona responsable de revisar pendientes y un procedimiento para reanudar con control. Reducir la frecuencia, agrupar lecturas permitidas o evitar consultas innecesarias puede ser más útil que contratar una cuota mayor. Una automatización empresarial debe hacer visible el trabajo que no pudo completar, sin prometer continuidad absoluta.
El siguiente paso
Comparte qué sistemas conectas, qué operaciones son urgentes y cuánto puede esperar cada tarea. Podemos definir una cola con límites y revisión antes de ampliar la automatización.
Automatización de procesos comerciales · Conversar sobre tu proyecto ↗
Fuentes y alcance
Fuentes consultadas el 3 de noviembre de 2026. Las recomendaciones de proceso son propuestas editoriales de Nicho; los ejemplos identificados como hipotéticos no representan resultados de clientes.
Contenido preparado con asistencia de IA y comprobaciones automáticas. No sustituye una evaluación de tu implementación ni garantiza resultados. Escríbenos si encuentras algo que debamos corregir.