El límite de peticiones API es la cuota de llamadas que una herramienta como HubSpot, Google Ads o Meta deja hacer en un periodo de tiempo antes de devolver un error. Para un equipo de marketing que sincroniza leads, campañas o informes entre varias plataformas, es el techo invisible que decide si esa automatización funciona a diario o se cae cada vez que hay más actividad de la habitual. Afecta igual a una empresa industrial que factura sus leads por CRM que a un ecommerce que sube catálogos a Google Ads.
El límite de peticiones API es el número máximo de llamadas que una plataforma acepta en un intervalo fijo; al superarlo, la API responde con un error (429 en HubSpot, código 17 en Meta) y rechaza el resto hasta que se reinicia la ventana.
Así funciona el límite de peticiones de una API
Toda API de marketing reparte su capacidad en ventanas de tiempo: por segundo, por cada 10 segundos o por hora, según el servicio. Mientras la cuenta se mantiene por debajo de ese techo, cada llamada se procesa con normalidad. Al superarlo, la plataforma no encola la petición ni la retrasa: la rechaza con un código de error y obliga a reintentarla cuando la ventana se reinicie.
La cuota no es uniforme ni fija para siempre. Cada proveedor la reparte por app, por cuenta conectada o por hora según el nivel de acceso que tenga el desarrollo que llama a su API, y la mayoría la sube o la baja sin avisar por correo: solo se nota cuando empiezan a fallar sincronizaciones que llevaban meses funcionando. Por eso conviene mirarla antes de construir una integración, no después de que falle en producción.
Cuánta cuota reparte cada API de marketing
Las cifras cambian mucho de un proveedor a otro, y también dentro del mismo proveedor según el nivel de acceso que tenga la app que conecta las herramientas. Conocerlas de antemano es lo que distingue una integración que aguanta una campaña fuerte de una que se cae justo el día que más tráfico mueve.
Google Ads pasa de 2.880 a ilimitado según el acceso
La documentación de la Google Ads API fija tres niveles: el acceso Explorer permite 2.880 operaciones diarias contra cuentas en producción, el acceso Basic sube a 15.000 operaciones al día y el acceso Standard elimina el tope diario por completo. Encima de esa cuota diaria hay un límite de 600 peticiones por minuto por token de desarrollador, que aplica a todas las cuentas de cliente que use ese token, y cada petición de modificación (mutate) no puede agrupar más de 10.000 operaciones. El servicio de planificación de palabras clave, además, limita a una petición por segundo por cliente: una agencia que lanza varios informes de keywords a la vez lo nota antes que en ningún otro sitio.
Qué pasa si superas el límite de peticiones
El síntoma casi nunca es un aviso claro. Es un lead que no llega al CRM, un informe de Google Ads que se queda a medias o una campaña de Meta que tarda horas en reflejar el gasto real. Cada proveedor devuelve su propio código: HubSpot responde 429 cuando se pasa de las peticiones por segundo o por día, y la API de Marketing de Meta devuelve el código de error 17 cuando la cuenta publicitaria agota los puntos asignados a su ventana de uso.
El coste real no es el error en sí, sino lo que arrastra detrás. Un despacho de arquitectura en el Eixample que sincroniza formularios web con su CRM cada cinco minutos puede acumular retrasos de horas si nadie revisa los reintentos; una tienda online que sube catálogos a Google Ads puede quedarse con anuncios desactualizados un día entero. En ambos casos el dato existe, pero llega tarde, y en marketing un lead que se procesa doce horas después vale mucho menos que el mismo lead gestionado en minutos.
¿Te ayudamos con esto?
Cuéntanos tu caso
Si esto te afecta, escríbenos en dos líneas y te respondemos por email con una valoración concreta.
Cómo evitar el error 429 en tus integraciones
La mayoría de estos fallos no se arreglan pidiendo más cuota: se evitan diseñando la integración para que nunca la agote. Las medidas que de verdad marcan la diferencia son pocas y conocidas:
- Leer la cabecera de uso que devuelve cada API y frenar antes de llegar al 100%, no después.
- Agrupar operaciones en lotes en vez de lanzar una llamada por registro, que es lo que agota antes la cuota de mutate de Google Ads.
- Sustituir el sondeo constante por webhooks, que solo llaman a la API cuando hay un cambio real.
- Cachear las respuestas que no cambian a cada minuto, como el catálogo de campañas o la lista de contactos.
Backoff exponencial evita que un fallo se multiplique
Cuando llega un 429, la reacción equivocada es reintentar en el acto: si la cuota ya está agotada, ese reintento inmediato solo añade otra llamada rechazada y, en integraciones mal hechas, un bucle que consume aún más cuota en el minuto siguiente. El backoff exponencial espera un segundo antes del primer reintento, dos antes del segundo, cuatro antes del tercero, y así hasta un tope razonable. Es la técnica que recomiendan tanto Google como Meta en su documentación de referencia, y la diferencia entre una integración que se recupera sola en segundos y otra que necesita que alguien la reinicie a mano al día siguiente.
Diseñar integraciones que resisten la cuota
Cuando la sincronización la monta un desarrollo a medida, el límite de peticiones debería formar parte del diseño desde el primer día, no descubrirse en producción. Eso significa poner una cola intermedia entre el formulario web y el CRM, para que un pico de tráfico no dispare cien llamadas simultáneas, y dar a cada operación un identificador propio para que un reintento no duplique el mismo lead dos veces.
Es el mismo problema de fondo que arrastran muchas integraciones con el CRM que se rompen sin motivo aparente: nadie diseñó qué pasa cuando la pieza del otro lado dice que no por un momento. Un desarrollo a medida en Barcelona que contemple esto desde el presupuesto inicial sale más caro en la propuesta y mucho más barato en el primer Black Friday o en la primera campaña que de verdad mueve volumen. Si tu empresa está evaluando quién construye o revisa esa integración, conviene pedir a la agencia de desarrollo de software que lo haga explícito en la propuesta, no como una nota a pie de página.
Preguntas frecuentes sobre los límites de API en marketing
¿Qué es el error 429 en una API?
Es la respuesta estándar HTTP para «demasiadas peticiones»: la plataforma ha detectado que se superó la cuota asignada en esa ventana de tiempo y rechaza la llamada sin procesarla. No es un fallo del servidor, sino un freno deliberado, y la solución es esperar y reintentar, no insistir de inmediato.
¿Cuántas peticiones permite la API de Google Ads?
Depende del nivel de acceso: 2.880 operaciones diarias en Explorer, 15.000 en Basic y sin tope diario en Standard, aunque siempre sujeto a 600 peticiones por minuto por token de desarrollador. El nivel se solicita y lo aprueba Google según el uso declarado de la app.
¿Puedo aumentar el límite de peticiones de mi CRM?
En HubSpot sí, con el add-on de ampliación de límite, que sube la cuota por app y por cuenta hasta dos veces sobre la base de tu plan. En Meta y Google Ads se consigue solicitando un nivel de acceso superior, que exige revisión y justificar el volumen de uso real de la app.
