Gestion de los límites de tasa
01En una frase #sec_56b85c74
Tres contadores independientes gobiernan la tasa — los datos, las pruebas, los tokens — y ciertas llamadas consumen dos a la vez.
02Los tres límites #sec_0a236919
| Contador | Límite por defecto | Lo que cuenta |
|---|---|---|
| Estándar | 600 por minuto | Todas las llamadas de la API |
| Pruebas | 60 por minuto | Las llamadas a evidence, además del estándar |
| Tokens | 60 por minuto | Las llamadas a /connect/token |
Estas son valores por defecto, no constantes: tu suscripción puede tener un límite más alto. Un aumento concedido por el editor entra en vigor desde la siguiente solicitud, sin reinicio ni tiempo de propagación.
03El contador de pruebas se suma, no reemplaza #sec_4b9c7978
Este es el punto que más sorprende. Una llamada a evidence decrementa los dos contadores: el de pruebas y el estándar. Un cliente que solo hiciera llamadas de pruebas se detendría a sesenta por minuto, no a seiscientos.
La razón es medible: cada llamada de prueba produce un PDF y lo firma, lo que supone unos 325 ms de procesador y criptografía. En el límite común, un solo cliente habría consumido cerca del 40 % de la máquina; a sesenta por minuto, alrededor del 4 %. El límite distinto existe para que la lentitud de un integrador no se convierta en la lentitud de todos.
04Lo que se cuenta, y para quién #sec_f6c8dcbb
El contador está vinculado al cliente autenticado, no a la dirección IP. Dos procesos que comparten un client_id comparten su límite, dondequiera que se ejecuten; dos clientes distintos en la misma máquina tienen cada uno el suyo.
El punto de llamada de tokens es una excepción antes de la autenticación: al no tener aún un cliente, cuenta por dirección IP.
Consecuencia práctica: si varias integraciones deben coexistir, dale a cada una su propio cliente en lugar de compartir un secreto. Dejarán de interferir entre sí, y un exceso designará a la culpable.
05El rechazo #sec_7af04e67
Un exceso devuelve 429 Too Many Requests, con un encabezado Retry-After y un cuerpo application/problem+json.
HTTP/1.1 429 Too Many Requests
Retry-After: 60
{
"type": "https://docs.reviewit.example/problems/rate-limit",
"title": "Too many requests",
"status": 429,
"detail": "The rate limit for this client has been exceeded. Retry after the indicated delay.",
"instance": "/api/v1/evidence/4821"
}instance lleva la ruta rechazada: en una integración que llama a varios dominios, es este campo el que indica cuál ha excedido.
06Reintentar #sec_41e4809f
El límite es una ventana fija de un minuto, no una tasa suavizada. El contador vuelve a cero al comienzo de cada minuto, no se recarga gradualmente.
Espera el tiempo indicado por Retry-After. Reintentar antes solo consume la ventana siguiente, y un cliente que se repite sin esperar queda bloqueado indefinidamente mientras simula una avería.
No hay cola de espera. Una llamada más allá del límite es rechazada inmediatamente, no se pone en espera. Esto es deliberado: una respuesta rápida que dice no es más útil que una respuesta lenta que acaba diciendo sí, porque deja al cliente la opción de ralentizar.
07Permanecer por debajo del límite #sec_767baf63
Tres acciones, en el orden en que se realizan.
La primera: guardar el token. Un token vive una hora; solicitar uno nuevo en cada llamada agota el límite de tokens —el más bajo de los tres— mucho antes que el de los datos.
La segunda: aumentar el tamaño de la página en lugar de multiplicar las llamadas. Quinientos elementos en una solicitud cuestan un token de débito; los mismos quinientos en cinco solicitudes cuestan cinco.
La tercera: espaciar las pruebas. Tienen su propio límite y también consumen el estándar; agruparlas en rafaga es la forma más rápida de topar con ambos.
08Para recordar #sec_2dde19f8
Seiscientos llamadas por minuto, sesenta para las pruebas que se añaden al estándar, sesenta para los tokens. Un contador por cliente autenticado. Un rechazo inmediato, nunca una cola de espera. Y Retry-After que dice exactamente cuánto tiempo esperar.