Docs / API

Los rate limits protegen la plataforma de bursts accidentales y de abuso. Se aplican en tres niveles.

Nivel 1 — Por API key

100 requests por minuto por API key, independiente del endpoint.

Al exceder: respuesta 429 con headers:

X-RateLimit-Limit: 100
X-RateLimit-Remaining: 0
X-RateLimit-Reset: 1720440060
Retry-After: 42

Retry-After viene en segundos.

Nivel 2 — Por tenant

1000 requests por minuto por tenant, sumando todas las keys y sesiones. Este límite es raro alcanzar con uso normal — protege de un pipeline mal configurado que quema todas las keys.

Nivel 3 — Por endpoint

Algunos endpoints tienen límites más estrictos por su costo:

EndpointLímite adicional
POST /v1/phishing/upload60 requests/minuto por tenant
POST /v1/phishing/{id}/detonate30 requests/hora por tenant
GET /v1/threats/query30 requests/minuto por tenant
GET /v1/tools/domain-intelConsume 1 unit del quota ip_intel_lookups

Estos límites reflejan costos de terceros (urlscan.io, VirusTotal, WHOIS providers).

Manejo recomendado

Backoff exponencial

import time
import random

def request_with_backoff(session, url, **kwargs):
    for attempt in range(6):
        r = session.request(url=url, **kwargs)
        if r.status_code != 429:
            return r
        retry_after = int(r.headers.get("Retry-After", "0"))
        wait = max(retry_after, 2 ** attempt + random.random())
        time.sleep(wait)
    raise Exception("rate limited after 6 retries")

Batching

En vez de un request por item, agrupá cuando sea posible:

  • GET /v1/reports?domain=a,b,c en vez de 3 requests separadas.
  • GET /v1/threats/iocs?since=<ts> con delta desde el último pull en vez de re-pull completo cada minuto.

Caching

Muchas respuestas son estables — cacheá lo que puedas:

  • GET /v1/domains — cambia raro. TTL 5 min razonable.
  • GET /v1/threats/iocs — feed. TTL 5 min razonable (cadence de update del feed).

Concurrencia

Distribuí requests en el tiempo, no en paralelo. Un pipeline con 10 workers pegándole al mismo endpoint agota el rate limit por key en segundos.

Excepciones — Enterprise

En tier Enterprise podés negociar rate limits ampliados si tu use case lo justifica. Común para clientes que integran múltiples SIEMs con pull frecuente.

Debugging

Si empezás a ver 429 en producción:

  1. Chequeá X-RateLimit-* headers para entender si estás cerca del límite normalmente o si hubo un spike.
  2. Mirá /settings/api-keys — ¿alguna key tiene volumen anormal?
  3. Considerá si podés cachear más.
  4. Si es sostenido → contactanos para revisar el límite.