Unif API Docs

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.

CabeceraSignificado
RateLimit-PolicyLa política como campo estructurado del IETF: "api-key";q=60;w=60 (q peticiones, w ventana en segundos)
RateLimitEstado actual, en la misma forma: "api-key";r=<restantes>;t=<segundos hasta el reinicio>
RateLimit-LimitPeticiones permitidas en una ventana
RateLimit-RemainingPeticiones que quedan en la ventana actual
RateLimit-ResetSegundos hasta que se reinicia la ventana: una diferencia, no una marca de tiempo Unix
X-RateLimit-Limit / -Remaining / -ResetAlias de las tres anteriores, para clientes que solo leen la grafía X-
Retry-AfterSegundos 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: 60

La 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:

  1. Regula el ritmo antes de que te limiten. Lee RateLimit-Remaining en cada respuesta y frena a medida que se acerque a 0. Esperar a un 429 para empezar a regular desperdicia un viaje de ida y vuelta en todos los workers a la vez.
  2. Respeta Retry-After. Es la espera que el limitador necesita de verdad; adivinar suele empeorar las cosas. Si falta, usa RateLimit-Reset. Subir la concurrencia tras un 429 nunca 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.

En esta página