Desarrolladores · Referencia
Límites de uso
Ritmo de llamadas, paginación y las dos ventanas de tiempo que importan: cuánto tarda generarse un informe, y cuánto dura fresco antes de recobrarse. Todo error de ritmo (429) trae el header Retry-After — nunca hay que adivinar cuánto esperar. Hoy esta página cubre los endpoints del Informe por CUIT; se va a extender a medida que sumemos APIs nuevas.
Ritmo de llamadas (rate limit)
| Endpoint | Límite | Nota |
|---|---|---|
| POST /v1/reports | 10 / minuto por cuenta | más 30/minuto por IP (protección compartida con el resto de este endpoint). |
| GET /v1/reports/quote | 20 / minuto por cuenta | — |
| GET /v1/balance | 20 / minuto por cuenta | — |
| GET /v1/reports | 30 / minuto por cuenta | — |
| GET /v1/reports/{id} | 10 / minuto por cuenta | más 30/minuto por IP. |
Tope diario de generación
Además del ritmo por minuto, hay un tope de 10 informes reales por día por cuenta (no cuentan los que se sirven cacheados desde las últimas 24h — ver abajo). Aplica sólo mientras tu cuenta opera bajo el modelo de tope diario; si tu cuenta ya factura por saldo (informes/actualizaciones, ver Cómo se compra), el saldo reemplaza al tope diario.
Cuánto tarda un informe
Generar un informe nuevo tarda 10-15 segundos (corre varias fuentes en paralelo). Ponele a tu cliente HTTP un timeout de 60 segundos — requests de Python y net/http de Go no traen timeout por default.
Frescura: 24 horas
Si tu cuenta ya generó el informe de un CUIT en las últimas 24 horas y el contenido sigue vigente, POST /v1/reports devuelve ese mismo informe (cache_hit: true) sin volver a correr el Motor ni cobrar de nuevo.
Paginación
GET /v1/reports devuelve hasta 50 items por página (default 10) — usá limit y offset, y mirá has_more para saber si seguir pidiendo.