Los límites de tasa de la API de Pinnacle son un presupuesto, no un muro.

Cómo es una respuesta de límite de la API de Pinnacle

Supera la asignación por segundo y la API devuelve HTTP 429 Too Many Requests, normalmente con una cabecera Retry-After que indica cuántos segundos esperar antes del siguiente intento:

HTTP/1.1 429 Too Many Requests
Retry-After: 2
Content-Type: application/json

Trata el 429 como una señal, no como una excepción. Registra cada aparición con su marca de tiempo y la llamada que la provocó: un recuento creciente de 429 es un aviso temprano de que la carga en régimen se acerca al techo. Retry-After es la autoridad. Cuando está presente, anula cualquier calendario que tu cliente tuviera en mente, y machacar a través de un 429 sin esperar es como un límite transitorio se convierte en un estrangulamiento más largo.

Backoff que funciona

El patrón estándar es backoff exponencial con jitter: espera un retardo base, duplícalo tras cada rechazo, ponle un tope y añade aleatoriedad para que los workers paralelos no reintenten al unísono.

delay = 0.5        # seconds
max_delay = 30
loop:
    res = get(url)
    if res.status != 429:
        return res
    wait = res.headers["Retry-After"] ?? delay
    sleep(wait + random(0, wait / 2))
    delay = min(delay * 2, max_delay)

Tres reglas lo hacen funcionar en producción. Respeta siempre Retry-After cuando exista la cabecera, porque el servidor conoce su propia ventana mejor que tu estimación. Limita el total de intentos y da por fallido el ciclo en lugar de bloquear el siguiente; las cuotas estarán más frescas en cinco segundos de todos modos. Comparte el estado de backoff entre workers, porque diez procesos retrocediendo educadamente siguen sumando diez veces las solicitudes.

Diseñar el margen

El backoff es triaje; el margen es prevención. Mantén el uso en régimen por debajo de aproximadamente el 70 por ciento de la cuota por segundo. En un nivel de 10 solicitudes por segundo eso significa marcar el ritmo del sondeo regular a 7 por segundo o menos, y reservar el resto para reintentos, herramientas de administración y un segundo entorno.

Los días de partido son la prueba. Las solicitudes de tablero se mantienen planas cuando la jornada crece, pero las llamadas de detalle por evento, los reintentos y las ráfagas de reconexión no, como muestra la planificación de capacidad, y las primeras respuestas 429 suelen llegar durante las jornadas más grandes, cuando los datos obsoletos cuestan más. Si tu estimación máxima está al 80 o 90 por ciento del techo, la respuesta es un nivel mayor o un alcance menor, no reintentos más ajustados. Los niveles comparados en este sitio difieren sobre todo en la tasa por segundo, que es exactamente la dimensión donde vive el margen.

Ver planes de capacidad

Cuando el sondeo deja de escalar

El coste del sondeo crece linealmente con la frescura: reduce el intervalo a la mitad y duplicas las solicitudes, en cada tablero que sondeas, todo el día. Pasado un punto la curva deja de tener sentido. Si tu producto necesita percepción por debajo de 2 segundos en una jornada completa, el sondeo REST es la herramienta equivocada para la ruta crítica.

La alternativa es push en lugar de pull. Las alertas de caída por SSE transmiten los cambios de cuotas procesados a medida que ocurren, mientras REST sigue activo para el arranque y la reconciliación periódica. El sondeador pide un snapshot; el stream te dice qué acaba de moverse, y los límites por segundo dejan en gran medida de ser tu problema.

La disciplina de sondeo de integración REST eficiente sigue aplicándose al lado REST de esa división, y la comparación de planes muestra qué niveles incluyen el stream.

Un bucle que ya gestiona el 429 tal como describe esta página está en el quickstart de Node.js en pnclFEED, donde el Retry-After fija la espera.

Obtener acceso a la API