Límites de tasa
El límite por clave de API, las cabeceras que lleva cada respuesta y cómo debe regular su ritmo un agente.
UnifAPI aplica un único límite de peticiones: 60 peticiones cada 60 segundos, por clave de API. Está acotado a la clave, no al espacio de trabajo ni al endpoint: dos claves del mismo espacio de trabajo no compiten por el mismo presupuesto, y ninguna operación tiene un límite propio más estricto.
Cabeceras
Cada respuesta — 2xx, 4xx o 5xx — lleva la cuota que se le aplica, así que nunca necesitas una petición de sondeo para saber en qué punto estás.
| Cabecera | Significado |
|---|---|
RateLimit-Policy | La política como campo estructurado del IETF: "api-key";q=60;w=60 (q peticiones, w ventana en segundos) |
RateLimit | Estado actual, en la misma forma: "api-key";r=<restantes>;t=<segundos hasta el reinicio> |
RateLimit-Limit | Peticiones permitidas en una ventana |
RateLimit-Remaining | Peticiones que quedan en la ventana actual |
RateLimit-Reset | Segundos hasta que se reinicia la ventana: una diferencia, no una marca de tiempo Unix |
X-RateLimit-Limit / -Remaining / -Reset | Alias de las tres anteriores, para clientes que solo leen la grafía X- |
Retry-After | Segundos de espera; se envía en un 429 originado por UnifAPI |
Una respuesta que nunca resolvió una clave de API — un 401, por ejemplo — informa de la política por defecto con el presupuesto completo. Describe la cuota que encontrarás una vez autenticado, no el consumo que ya has gastado.
Los clientes de navegador pueden leerlas todas: aparecen en Access-Control-Expose-Headers en las respuestas de origen cruzado.
HTTP/1.1 200 OK
RateLimit-Policy: "api-key";q=60;w=60
RateLimit: "api-key";r=57;t=60
RateLimit-Limit: 60
RateLimit-Remaining: 57
RateLimit-Reset: 60La ventana
La ventana se ancla en la petición más reciente de la clave: el contador se reinicia cuando pasa una ventana completa sin llamadas de esa clave. No hay margen de ráfaga, así que diseña para la tasa sostenida y no para un saldo acumulado.
Gestionar un 429
async function call(url: string, init: RequestInit, attempt = 0): Promise<Response> {
const res = await fetch(url, init);
if (res.status !== 429 || attempt >= 5) return res;
const wait = Number(res.headers.get("Retry-After") ?? res.headers.get("RateLimit-Reset") ?? 1);
await new Promise((r) => setTimeout(r, wait * 1000));
return call(url, init, attempt + 1);
}Dos reglas para el día a día:
- Regula el ritmo antes de que te limiten. Lee
RateLimit-Remainingen cada respuesta y frena a medida que se acerque a0. Esperar a un429para empezar a regular desperdicia un viaje de ida y vuelta en todos los workers a la vez. - Respeta
Retry-After. Es la espera que el limitador necesita de verdad; adivinar suele empeorar las cosas. Si falta, usaRateLimit-Reset. Subir la concurrencia tras un429nunca ayuda: el límite es por clave.
Pedir más
Los límites se fijan por clave, así que un límite más alto es un cambio de configuración y no una mejora de plan. Escribe a support@unifapi.com con el ID de tu espacio de trabajo, la Skill u operación que ejecutas y una estimación aproximada de QPS.