Error 429 en Power Automate: entender y solucionar el throttling

El error 429 (Too Many Requests) en Power Automate significa que un flow ha superado el límite de solicitudes de un conector o de la plataforma dentro de una ventana de tiempo corta y, por ello, se ve sometido a throttling. La causa más frecuente es un conector con un límite de tiempo estricto, como el conector de SharePoint con un tope de 600 acciones por minuto, o un flow con muchas ejecuciones paralelas o iteraciones de bucle. La solución suele consistir en reducir el control de concurrencia (Concurrency Control), filtrar los datos con mayor precisión y sustituir las acciones individuales recurrentes por operaciones de batching. Fecha: julio de 2026.

¿Qué causa el error 429 en Power Automate?

El error 429 se produce cuando un flow envía a un conector más solicitudes de las que su mecanismo de protección del servicio permite dentro de una ventana de tiempo. Según la documentación oficial sobre los límites de la plataforma y el throttling el servicio devuelve entonces el código de error 429 con un mensaje como «Se ha superado el límite de frecuencia. Vuelva a intentarlo en 27 segundos». Este throttling de conector es independiente de los límites de acciones diarios de su plan de licencia: por lo tanto, un flow puede sufrir throttling aunque la cuota diaria esté lejos de agotarse. Los desencadenantes típicos son bucles con muchas iteraciones, varias instancias de flow ejecutándose simultáneamente o un único conector utilizado en paralelo por varios flows.

¿Qué límites debe tener en cuenta?

Las cifras exactas varían según el conector y la licencia, pero algunos valores de referencia están claramente documentados. El conector de SharePoint, por ejemplo, limita el número de acciones a 600 por minuto, por conexión en todos los flows y no por flow individual, como describe la FAQ de licencias de Power Automate Además, se aplica un límite de ráfaga de acciones a nivel de plataforma, actualmente de 100.000 acciones por flow en cinco minutos. Independientemente de esto, existen límites diarios de solicitudes de API que dependen de su plan de licencia y que se aplican a todas las ejecuciones de flow de un usuario en 24 horas. Importante para la resolución de problemas: tanto las acciones correctas como las fallidas cuentan para estos límites, al igual que los reintentos y las solicitudes adicionales debidas a la paginación.

¿Cómo se solucionan los errores 429 mediante el control de concurrencia?

La palanca más directa es reducir el grado de concurrencia en el desencadenador o en los bucles. Microsoft recomienda exactamente este paso en la guía sobre «Demasiadas solicitudes» en Power Automate ante un error 429: en la configuración del desencadenador o de la acción, en «Control de concurrencia» (Concurrency Control), se puede limitar el grado de concurrencia. Por defecto, el control de concurrencia está desactivado para los desencadenadores, pero puede establecerse en un valor entre 1 y 100, con 25 ejecuciones simultáneas como valor predeterminado al activarlo. Para los bucles «Aplicar a cada uno», se aplica un valor de concurrencia propio que, según los límites para flows es de 1 por defecto y puede aumentarse hasta 50, o mantenerse deliberadamente bajo para evitar errores. Si un flow alcanza repetidamente el límite del conector, reducir deliberadamente estos valores suele ser el remedio más rápido, aunque el flow se ejecute entonces algo más lento.

¿Cómo ayuda el batching a evitar el throttling de forma permanente?

El batching reduce el número de solicitudes individuales que pueden ser sometidas a throttling. En lugar de ejecutar una acción independiente para cada registro en un bucle, según la guía sobre evitar antipatrones varias operaciones de creación o actualización pueden agruparse en una única solicitud HTTP mediante solicitudes batch, siempre que el conector correspondiente lo admita. Para los servicios sin soporte de batch, el procesamiento paralelo controlado en el bucle «Aplicar a cada uno» es la alternativa, con hasta 50 registros simultáneos según Microsoft. También merece la pena revisar los parámetros de filtro de consulta y de recuento máximo (top count) de muchos conectores para recuperar menos registros desde el principio, así como los bucles anidados, que pueden multiplicar rápidamente el número de solicitudes. Quien desee que su entorno de Power Automate sea fundamentalmente más estable encontrará en la consultoría de Power Automate de NordFlux apoyo en la arquitectura de flows, la elección de licencia y la resolución de problemas de throttling recurrente.

Preguntas frecuentes sobre el throttling de Power Automate (429)

¿Por qué recibo errores 429 aunque no se haya alcanzado mi límite de acciones diario?

Porque el throttling de conector funciona de forma independiente a los límites diarios de solicitudes de API. Cada conector, como SharePoint con su límite de 600 acciones por minuto, aplica su propia ventana de tiempo a corto plazo, que puede superarse incluso con un uso diario bajo si se ejecutan muchas acciones en poco tiempo.

¿Ayuda un plan de licencia más caro contra los errores 429?

Un plan de licencia superior aumenta principalmente la cuota de acciones diaria, no los límites de throttling específicos del conector. Dado que el error 429 suele estar provocado por el throttling del conector, ajustar la concurrencia y el diseño del flow suele ser más eficaz que actualizar la licencia.

¿Cuál es la diferencia entre el límite de ráfaga de acciones y el throttling de conector?

El límite de ráfaga de acciones es un tope a nivel de plataforma, actualmente de 100.000 acciones por flow en cinco minutos, mientras que el throttling de conector se aplica por cada servicio de conector individual y varía mucho según el servicio. Ambos pueden provocar de forma independiente un error 429, por lo que es mejor determinar la causa a partir del mensaje de error exacto y del historial de ejecución del flow.

¿Puedo simplemente evitar los errores 429 con reintentos automáticos?

Los reintentos automáticos no resuelven el problema subyacente, porque las acciones fallidas y los reintentos también cuentan para los límites de solicitudes. Es más útil abordar la causa mediante el control de concurrencia, el filtrado y el batching, en lugar de simplemente dejar que el flow reintente con más frecuencia.