Rate limits
Límites de uso por plan
Aplicamos rate limit por API key, en una ventana móvil de 1 hora. Los uploads directos a R2 con presigned URLs NO cuentan contra este límite — solo cuentan llamadas a endpoints /v1/*.
Límites por plan
| Plan | Requests/hora | Notas | |
|---|---|---|---|
| Free | 100 | — | Suficiente para evaluar e integrar. |
| Pro | 1.000 | — | Cubre la mayoría de centros radiológicos. |
| Clínica | 5.000 | — | Para integraciones con PMS o marketplaces. |
| Ultra | 10.000 | — | Tope estándar. Encima de esto pedí Enterprise. |
| Enterprise | > 10.000 (a medida) | — | Acuerdo a medida + SLA dedicado. Escribinos a soporte@cbcthub.com. |
Las keys de sandbox (cbct_test_*) usan un bucket separado con 1.000 req/h, independiente del plan. No consumen tu cuota de producción.
Puedes ver el consumo en tiempo real de cada key en /dashboard/api/usage (gráfico por hora, llamadas por endpoint y 429 recientes).
Cuando pasas el límite
http
HTTP/1.1 429 Too Many Requests
Retry-After: 1847
X-RateLimit-Limit: 1000
X-RateLimit-Reset: 1780201234
{
"error": {
"code": "rate_limited",
"message": "Rate limit exceeded (1000 requests/hour). Retry in 1847s.",
"retry_after_seconds": 1847
}
}Headers de respuesta
En cada respuesta 429 te devolvemos estos headers para que implementes backoff correctamente:
Retry-After— segundos hasta que se resetee la ventanaX-RateLimit-Limit— tu límite actual por horaX-RateLimit-Reset— timestamp Unix cuando se resetea
Mejores prácticas
- Haz cache de la respuesta de GET /v1/me — no la llames antes de cada operación.
- Para subir muchos exámenes en batch, paraleliza con un semáforo (ej: 10 concurrentes).
- Si necesitas más de 10.000 requests/hora sostenido, escríbenos: armamos un acuerdo Enterprise a medida.