> ## Documentation Index
> Fetch the complete documentation index at: https://docs.fluz.app/llms.txt
> Use this file to discover all available pages before exploring further.
# Límites de tasa
> Fluz aplica límites de tasa protectores por servicio para mantener la plataforma estable. Cuáles son los límites, cómo se ve un 429 y cómo crear clientes que se mantengan dentro de ellos.
Fluz no vende cuotas de API por plan: no hay niveles de “Free = X req/min, Pro = Y req/min” ni un sistema de cuotas por clave. En su lugar, cada servicio aplica un **límite de tasa protector** para absorber abusos y proteger su backend. El tráfico normal interactivo y de aplicaciones prácticamente nunca alcanza estos límites; existen para atrapar scripts descontrolados y abuso.
No hay cuotas publicadas por plan para solicitar un aumento. Si una integración bien comportada está alcanzando límites, eso generalmente apunta a un patrón de tráfico que conviene corregir (ver [Crea un cliente bien comportado](#build-a-well-behaved-client)) más que a una cuota que deba incrementarse.
## Cómo se aplican los límites
Los límites se hacen cumplir de forma independiente **por servicio** y se evalúan globalmente a través de las instancias de ese servicio: no puedes escapar de un límite llegando a un servidor diferente. Una solicitud se identifica por una combinación de:
* **Tu dirección IP**: cada solicitud cuenta contra un límite por IP.
* **Tu token de acceso**: el encabezado completo `Authorization`. Las solicitudes sin encabezado de autenticación omiten el limitador por token pero aún cuentan contra el limitador por IP, así que envía un token estable para que te limiten como *tú* en lugar de agruparte con todos los que comparten una IP.
* **La ruta del endpoint**: en algunas superficies públicas, rutas específicas tienen sus propios límites.
Exceder cualquier límite devuelve **HTTP `429 Too Many Requests`**.
## Límites de tráfico por superficie
Estos son límites sostenidos por segundo. Cuando se exceden, la clave se bloquea por un breve enfriamiento antes de que se vuelvan a aceptar solicitudes.
| Superficie | Límite | Enfriamiento después de exceder |
| ------------------------------------------------------------------------- | ----------------------------------------- | ------------------------------- |
| **GraphQL API** — el endpoint transaccional del grafo (`/api/v1/graphql`) | 20 solicitudes / segundo | 10 segundos |
| **Operaciones de proveedores de tarjetas de regalo** | 20 solicitudes / segundo | 10 segundos |
| **Grafo social** (contactos, invitaciones, seguimientos) | 50 solicitudes / segundo | 10 segundos |
| **Otros servicios** (predeterminado) | 10 solicitudes / segundo | siguiente solicitud rechazada |
| **Pasarela móvil / app** | Límites protectores ajustados por entorno | — |
El endpoint de GraphQL API es el que la mayoría de las integraciones llaman para depósitos, compras, transferencias y revelaciones; planea alrededor de **20 solicitudes por segundo** allí. Los límites por IP, por token y por endpoint de la pasarela móvil/app se configuran por entorno y no se publican como números fijos; trátalos como protectores y retrocede ante `429`.
## Autenticación y seguridad
Los flujos de inicio de sesión, PIN y de dos factores (2FA) están protegidos por separado del tráfico general de la API. Intentos fallidos repetidos —inicios de sesión, verificaciones de PIN o verificación de 2FA— y solicitudes excesivas de 2FA o SMS desencadenan bloqueos temporales que se borran solos después de un enfriamiento. Una autenticación exitosa restablece estos contadores.
No reintentes automáticamente inicios de sesión, verificaciones de PIN o 2FA fallidos. Muestra al usuario un estado de “intenta de nuevo más tarde”; los reintentos automáticos prolongan el bloqueo.
## Cuando excedas un límite
Cada respuesta limitada por tasa usa el estado **`429 Too Many Requests`**. El cuerpo y los encabezados varían según la superficie:
```json GraphQL / web / vendor services theme={null}
{
"message": "Rate limit exceeded"
}
```
```json Gateway / auth services (standardized error) theme={null}
{
"success": false,
"msg": "Too many requests, please try again later",
"errorRecord": {
"code": "G-0002",
"name": "RatelimitExceeded"
}
}
```
La disponibilidad de encabezados no es uniforme:
* **`Retry-After`** (segundos enteros) se devuelve en el limitador por IP de autenticación y en los flujos de PIN/2FA. **No** está garantizado en los limitadores de tráfico general de GraphQL/web.
* Actualmente **no** hay encabezados `X-RateLimit-Limit`, `X-RateLimit-Remaining` o `X-RateLimit-Reset`; no construyas lógica que dependa de ellos.
## Crea un cliente bien comportado
Respeta `Retry-After` cuando esté presente. Cuando no lo esté, retrocede exponencialmente comenzando alrededor de 1 segundo (1s → 2s → 4s…) en lugar de reintentar de inmediato.
No bombardees en paralelo una superficie desde una sola IP o token. Para la GraphQL API, mantente cómodamente por debajo de 20 solicitudes/segundo y suaviza los picos.
Fallas repetidas de inicio de sesión, PIN o 2FA causan bloqueos temporales. Muestra al usuario un mensaje de “intenta de nuevo más tarde” en lugar de reintentar automáticamente.
Autentica cada solicitud con tu token para que los límites basados en token se apliquen específicamente a tu tráfico, en lugar de agregarse con otros detrás de una IP compartida.
Debido a que `Retry-After` no está garantizado en todas partes, combina tu lógica de reintentos con [claves de idempotencia](/concepts/idempotency) para que una mutación reintentada nunca procese dos veces una compra o transferencia. Para el catálogo completo de errores, consulta [Errores](/api-reference/errors).