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) 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.
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.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.Cuando excedas un límite
Cada respuesta limitada por tasa usa el estado429 Too Many Requests. El cuerpo y los encabezados varían según la superficie:
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-RemainingoX-RateLimit-Reset; no construyas lógica que dependa de ellos.
Crea un cliente bien comportado
1
Trata 429 como reintento posible
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.2
Mantén tasas sostenidas modestas
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.
3
No reintentes automáticamente fallas de autenticación
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.
4
Envía un token de acceso estable
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.
Retry-After no está garantizado en todas partes, combina tu lógica de reintentos con claves de idempotencia para que una mutación reintentada nunca procese dos veces una compra o transferencia. Para el catálogo completo de errores, consulta Errores.