Limitación de tasa para APIs públicas que detiene el abuso sin bloquear a usuarios reales: límites prácticos, cuotas por clave, bloqueos y consejos de implementación.
La limitación de tasa para APIs públicas no se trata de castigar a los usuarios. Es una válvula de seguridad que mantiene tu servicio disponible cuando el tráfico se vuelve raro, ya sea porque ese «raro» es malicioso o simplemente un bug en un cliente.
El «abuso» a menudo parece normal al principio: un scraper que recorre cada endpoint para copiar datos, intentos de fuerza bruta en inicios de sesión, token stuffing contra rutas de autenticación, o un cliente desbocado que reintenta la misma petición en un bucle cerrado tras un timeout. A veces nadie te está atacando: una actualización de la app móvil incluye una mala regla de caché y de pronto cada dispositivo consulta tu API cada segundo.
El trabajo es sencillo: proteger la disponibilidad y controlar costes sin bloquear a usuarios reales que hacen su trabajo normal. Si tu backend se factura por uso (cómputo, base de datos, email/SMS, llamadas a IA), un actor ruidoso puede multiplicar la factura muy rápido.
La limitación de tasa por sí sola tampoco basta. Sin monitorización y respuestas claras, obtienes fallos silenciosos, clientes confundidos y tickets de soporte que suenan a «tu API está caída» cuando en realidad está aplicando throttling.
Una protección completa suele tener varias piezas separadas:
Si estás construyendo un backend de API en una plataforma como AppMaster, estas reglas siguen importando. Incluso con código limpio y regenerado, querrás valores por defecto protectores para que un cliente defectuoso no tumbe todo tu servicio.
Estos términos se mezclan, pero resuelven problemas distintos y se perciben distinto por los usuarios.
Un límite de tasa es un límite de velocidad: cuántas peticiones puede hacer un cliente en una ventana corta (por segundo, por minuto). Una cuota es un presupuesto: uso total en un periodo más largo (por día, por mes). Un límite de concurrencia pone cota a cuántas peticiones pueden estar en curso al mismo tiempo, útil para endpoints caros incluso cuando la tasa parece normal.
Dónde aplicas el límite importa:
El throttling suave ralentiza al cliente (retardos, menor capacidad de ráfaga) para que pueda recuperarse sin romper flujos. El bloqueo duro rechaza peticiones inmediatamente, normalmente con HTTP 429.
Un bloqueo es más fuerte que un 429 normal. Un 429 dice «intenta de nuevo pronto». Un bloqueo dice «detente hasta que se cumpla una condición», como un periodo de enfriamiento, una revisión manual o un reinicio de la clave. Reserva bloqueos para señales claras de abuso (credential stuffing, scraping agresivo, intentos repetidos de auth inválida), no para picos normales.
Si construyes una API con una herramienta como AppMaster, trata estos controles por separado: límites en ventanas cortas para ráfagas, cuotas largas para controlar costes, y bloqueos solo para comportamiento repetidamente malo.
Buenos límites empiezan con un objetivo: proteger el backend dejando que los usuarios normales terminen su trabajo. No necesitas números perfectos el primer día. Necesitas una base segura y una forma de ajustarla.
Un punto de partida simple es un límite por clave de API que encaje con el tipo de API que ofreces:
Luego divide límites por tipo de endpoint. Las lecturas suelen ser más baratas y pueden admitir límites más altos. Las escrituras modifican datos, a menudo desencadenan lógica extra, y merecen topes más estrictos. Un patrón común es 1.000/min para rutas GET y 100-300/min para POST/PUT/DELETE.
También identifica endpoints costosos y trátalos por separado: búsquedas, generación de informes, exportaciones, subidas de archivos y cualquier cosa que toque varias tablas o ejecute lógica de negocio pesada deberían tener un bucket más pequeño incluso si el resto de la API es generoso. Si tu backend usa flujos visuales (por ejemplo, Business Process flows), cada paso añadido es trabajo real que se multiplica bajo carga.
Planifica ráfagas con dos ventanas: una corta para absorber picos rápidos y otra más larga que controle el uso sostenido. Una combinación común es 10 segundos más 10 minutos. Ayuda a usuarios reales que hacen clic rápido, sin dar velocidad ilimitada a los scrapers.
Finalmente, decide qué ocurre cuando el cliente excede el límite. La mayoría de las APIs públicas devuelven HTTP 429 con un tiempo de reintento claro. Si el trabajo se puede demorar sin problemas (por ejemplo, una exportación), considera encolarlo en lugar de bloquearlo para que los usuarios reales sigan obteniendo resultados.
Las cuotas por clave suelen ser el enfoque más justo porque coinciden con cómo los clientes usan tu servicio: una cuenta, una clave, responsabilidad clara. Los límites por IP siguen siendo útiles, pero a menudo castigan a usuarios inocentes.
Las IPs compartidas son la razón principal. Toda una oficina puede salir por una sola IP pública, y las operadoras móviles pueden poner miles de dispositivos detrás de un pequeño pool de IPs. Si te basas en límites por IP, un usuario ruidoso puede ralentizar a todos los demás. Una cuota por clave evita eso, y puedes mantener un límite por IP ligero como respaldo frente a inundaciones obvias.
Para que las cuotas se sientan justas, átalas a los niveles de cliente sin atrapar a los nuevos usuarios. Una clave gratuita o de prueba debe servir para pruebas reales, pero no para una escala que te perjudique. Un patrón simple es ráfagas generosas, una tasa sostenida moderada y una cuota diaria acorde al plan.
Una política por clave que sea predecible:
Para desalentar el intercambio de claves y los registros automatizados, no necesitas vigilancia intensa. Empieza con comprobaciones simples como cambios geográficos inusuales, demasiadas IPs distintas por hora para una clave, o muchas claves nuevas creadas desde la misma fuente. Señala y ralentiza primero; bloquea solo tras señales repetidas.
El tráfico anónimo es donde convienen topes más estrictos. Si ofreces claves de prueba, limítalas con fuerza y exige un paso básico de verificación antes de subir límites. Si tu API alimenta un formulario público, considera un endpoint anónimo separado con su propia cuota para proteger el resto del backend.
Si construyes tu API con una plataforma como AppMaster, la lógica por clave es más fácil de mantener consistente porque la auth, las reglas de negocio y el manejo de respuestas conviven en un mismo lugar.
La limitación de tasa funciona a largo plazo solo si los clientes pueden entender qué pasó y qué hacer después. Apunta a respuestas predecibles: mismo código de estado, mismos campos, mismo significado en todos los endpoints.
Cuando un cliente alcanza un límite, devuelve HTTP 429 (Too Many Requests) con un mensaje claro y un tiempo de espera concreto. La ganancia más rápida es añadir Retry-After, porque incluso clientes simples pueden pausar correctamente.
Un pequeño conjunto de cabeceras hace los límites autoexplicativos. Mantén nombres consistentes e inclúyelos tanto en respuestas exitosas (para que los clientes se regulen) como en respuestas 429 (para que puedan recuperarse):
Retry-After: segundos a esperar antes de reintentarX-RateLimit-Limit: peticiones permitidas en la ventana actualX-RateLimit-Remaining: peticiones restantes en la ventana actualX-RateLimit-Reset: cuándo se reinicia la ventana (epoch seconds o tiempo ISO)X-RateLimit-Policy: texto corto como "60 requests per 60s"Haz que el cuerpo de error sea tan estructurado como tus respuestas exitosas. Un patrón común es un objeto de error con un code estable, un message legible y pistas de recuperación.
{
"error": {
"code": "rate_limit_exceeded",
"message": "Too many requests. Please retry after 12 seconds.",
"retry_after_seconds": 12,
"limit": 60,
"remaining": 0,
"reset_at": "2026-01-25T12:34:56Z"
}
}
Indica a los clientes cómo retroceder al ver 429s. El backoff exponencial es un buen valor por defecto: espera 1s, luego 2s, luego 4s, y ponle un tope (por ejemplo, 30-60 segundos). También sé explícito sobre cuándo dejar de reintentar.
Evita sorpresas cerca de las cuotas. Cuando una clave esté cerca de su tope (por ejemplo, 80-90% usado), incluye un campo o cabecera de advertencia para que los clientes puedan ralentizarse antes de empezar a fallar. Esto importa aún más cuando un script puede golpear múltiples rutas rápido y quemar presupuesto más deprisa de lo esperado.
Un despliegue funciona mejor cuando tratas los límites como un comportamiento de producto, no como una regla de firewall puntual. El objetivo es el mismo: proteger el backend manteniendo a los clientes normales en movimiento.
Arranca con un inventario rápido. Lista cada endpoint y márcalo por coste (CPU, trabajo en BD, llamadas a terceros) y riesgo (login, restablecimiento de contraseña, búsqueda, subida de archivos). Eso evita aplicar un único límite contundente por todas partes.
Un orden de despliegue que suele evitar sorpresas:
Mantén la primera versión conservadora. Es más fácil aflojar después que desbloquear usuarios enfadados.
Monitoriza y afina, luego versiona tu política. Controla cuántas peticiones alcanzan límites, qué endpoints las disparan y cuántas claves únicas se ven afectadas. Cuando cambies números, trátalo como un cambio de API: documéntalo, desplázalo gradualmente y separa reglas viejas y nuevas para poder revertir rápido.
Si construyes tu API con AppMaster, planifica estas reglas junto a tus endpoints y lógica de negocio para que los límites reflejen el coste real de cada workflow.
Los bloqueos son el cinturón de seguridad. Deben detener el abuso obvio rápidamente, pero dar a los usuarios normales un camino claro de recuperación cuando algo falla.
Un enfoque calmado son las penalizaciones progresivas. Asume que el cliente podría estar mal configurado, no ser malicioso, y escala solo si el mismo patrón se repite.
Usa un conjunto pequeño de pasos que sean fáciles de explicar e implementar:
Elegir qué bloquear importa. Por clave de API suele ser lo más justo porque apunta al llamador, no a todos detrás de una red compartida. Por cuenta ayuda cuando los usuarios rotan claves. Por IP puede ayudar con tráfico anónimo, pero genera falsos positivos por NATs, oficinas y operadoras. Cuando el abuso es serio, combina señales (por ejemplo, bloquea la clave y exige comprobaciones adicionales para esa IP), pero mantén el radio de impacto pequeño.
Haz los bloqueos basados en tiempo con reglas simples: "bloqueado hasta 14:05 UTC" y "se reinicia tras 30 minutos de buen comportamiento". Evita bans permanentes en sistemas automatizados. Un cliente con bug puede entrar en bucle y quemar límites rápido, así que diseña penalizaciones que decaigan con el tiempo. Un periodo sostenido de bajo ritmo debería bajar el nivel de la penalización.
Si construyes tu API en AppMaster, esta escalera encaja bien con contadores almacenados y un Business Process que decide permitir, ralentizar o bloquear y escribe el tiempo de desbloqueo para la clave.
Para reincidentes, deja un camino de revisión manual. No discutas con los usuarios: pide IDs de petición, timestamps y el nombre de la clave, y decide con base en evidencias.
Los falsos positivos son cuando tus defensas bloquean usuarios normales. Suceden cuando las reglas son demasiado simples para cómo la gente usa realmente tu API.
Un error clásico es un límite global único para todo. Si tratas por igual un endpoint de lectura barato y una exportación cara, o bien sobreproteges el barato (molesto) o subproteges el caro (peligroso). Separa límites por coste de endpoint y haz los caminos pesados más estrictos.
Limitar solo por IP es otra trampa común. Muchos usuarios reales comparten una IP pública (oficinas, colegios, operadoras móviles). Un usuario pesado puede dejar a todos bloqueados y parece una caída aleatoria. Prefiere límites primarios por clave de API y usa la IP como señal secundaria para abuso obvio.
Las fallas también causan falsos positivos. Si tu tienda de limitación falla, «fallar cerrado» puede tumbar toda tu API. «Fallar abierto» puede invitar un pico que acabe tirando el backend igualmente. Elige un fallback claro: mantén un pequeño cap de emergencia en el borde y degrada con gracia en endpoints no críticos.
El manejo por parte del cliente importa más de lo que muchos equipos esperan. Si devuelves un 429 genérico sin mensaje claro, los usuarios reintentan más fuerte y disparan más bloqueos. Siempre envía Retry-After y mantén el texto de error específico ("Too many requests for this key. Try again in 30 seconds.").
El problema más evitable es la secretividad. Los límites ocultos parecen bugs cuando los clientes pasan a producción. Comparte una política simple y mantenla estable.
Lista rápida para evitar falsos positivos:
Retry-AfterSi construyes tu API con una herramienta como AppMaster, esto suele significar establecer topes distintos por endpoint y devolver payloads de error consistentes para que los clientes puedan retroceder sin adivinar.
La limitación de tasa solo funciona si puedes ver lo que pasa en tiempo real. El objetivo no es capturar cada pico, sino detectar patrones que se conviertan en caídas o en usuarios enfadados.
Empieza con un pequeño conjunto de señales que expliquen tanto volumen como intención:
Para separar «tráfico malo» de «hemos desplegado algo», añade contexto a los dashboards: hora de deploy, cambios en feature flags, envíos de marketing. Si el tráfico sube justo tras un release y la mezcla 429/5xx se mantiene sana, normalmente es crecimiento, no abuso. Si el pico se concentra en una clave, un rango de IP o un endpoint caro, trátalo como sospechoso.
Las alertas deben ser aburridas. Usa umbrales más cooldowns para no recibir un page cada minuto por el mismo evento:
Cuando salte una alerta, deja una nota corta del incidente: qué cambió, qué viste (claves/endpoints principales) y qué ajustaste (límites, cachés, bloqueos temporales). Con el tiempo, esas notas serán tu playbook real.
Ejemplo: lanzas un endpoint de búsqueda y el tráfico se duplica. Si la mayoría de llamadas van a ese endpoint entre muchas claves, sube un poco la cuota por clave y optimiza el endpoint. Si una clave lanza exportaciones sin fin y sube la latencia, capea ese endpoint por separado y contacta al propietario.
Una buena configuración es aburrida cuando funciona. Esta lista detecta los problemas que suelen crear falsos positivos o dejar huecos obvios.
Haz estas comprobaciones en staging y otra vez justo tras el lanzamiento:
Si construyes sobre AppMaster, trata cada endpoint nuevo como una decisión de nivel de coste: una consulta simple puede ser generosa, mientras que cualquier cosa que dispare lógica de negocio pesada debe empezar más estricta.
Protege el backend dejando que los usuarios reales se recuperen:
Antes de subir límites para un cliente, revisa su patrón normal de peticiones, mezcla de endpoints y si pueden agrupar o añadir backoff. También confirma que no estén compartiendo una clave entre muchas apps.
Mensualmente, revisa: endpoints más limitados, porcentaje de tráfico que alcanza límites, nuevas rutas costosas y si tus cuotas todavía coinciden con el uso real.
Imagina que gestionas una API pública usada por dos apps: un portal de clientes (alto volumen, tráfico estable) y una herramienta administrativa interna (bajo volumen, pero acciones poderosas). Ambas usan claves de API, y el portal además tiene un endpoint de login para usuarios finales.
Una tarde, un partner despliega una integración con bug. Empieza a reintentar peticiones fallidas en un bucle cerrado, enviando 200 peticiones por segundo desde una sola clave. Sin guardrails, esa clave puede acapararlo todo.
Los límites por clave contienen el radio de daño. La clave defectuosa llega a su tope por minuto, recibe un 429 y el resto de clientes siguen funcionando. También podrías tener un límite más bajo para endpoints costosos (como exportaciones) para que incluso el tráfico "permitido" no sobrecargue la base de datos.
Al mismo tiempo, un intento de fuerza bruta golpea el endpoint de auth. En vez de bloquear toda la IP (que puede afectar a usuarios reales detrás de NAT), lo ralentizas y luego lo bloqueas según comportamiento: demasiados fallos por cuenta además de por IP en una ventana corta. El atacante recibe esperas progresivamente más largas y luego un bloqueo temporal.
Un cliente real que escribió mal su contraseña unas cuantas veces puede recuperarse porque tus respuestas son claras y predecibles:
Retry-After para que el cliente sepa cuándo reintentarPara confirmar la solución, miras unas métricas:
Así es la limitación protectora: protege tu backend sin castigar a usuarios normales.
No necesitas un modelo perfecto el primer día. Empieza con una política pequeña y clara y mejórala según aprendas cómo se comportan los usuarios reales.
Una primera versión sólida suele tener tres partes:
Añade bloqueos solo donde el riesgo de abuso sea alto y la intención sea fácil de inferir. Signup, login, restablecimiento de contraseña y creación de tokens son candidatos típicos. Mantén los bloqueos cortos al principio (minutos, no días) y prefiere fricción progresiva: ralentizar, bloquear temporalmente y luego requerir una comprobación más fuerte.
Escribe la política en lenguaje llano para que soporte la explique sin ayuda de ingeniería. Incluye qué se limita (por clave de API, por IP, por cuenta), la ventana de reinicio y cómo puede recuperarse un cliente.
Si lo implementas mientras construyes un backend nuevo, AppMaster puede encajar bien: puedes crear APIs, definir workflows (incluidos contadores y decisiones de bloqueo) visualmente y desplegar a proveedores en la nube o exportar el código generado cuando necesites control total.
21 ene 2026
8 min
20 ene 20268 min
20 ene 20268 minExperimente con AppMaster con plan gratuito.
Cuando esté listo, puede elegir la suscripción adecuada.
