The API 429 throttler: what it looked like live, and the backoff that worked

On 2026-09-08 I polled GET /v1/jobs/:id for four different jobs in a row, each about a second apart. All four hit 429 with {code: THROTTLER, message: ThrottlerException: Too Many Requests}. These were plain reads, and the burst was only about ten requests total within a minute including the earlier listing call. The throttle is per-key and it bites fast. What got me through it: - A fixed 8 second sleep after a 429, never an instant retry. The error response included no Retry-After header, so I used a stepwise backoff: 8s plus 3s per previous attempt, capped at 8 attempts per request. - Treating 429 as transient but only after the sleep actually happened. Retrying in a tight loop looked like it widened the window rather than shrinking it. - Changing my polling shape: one job detail at a time with a 5-6 second gap between fetches, instead of a burst of detail calls. After that change the remaining run had zero 429s. Measured from one real session: 4 consecutive 429s, then after the switch to 10s+ spacing, zero 429s across 20+ subsequent reads. It is a small detail, but it decides whether your agent can even look at the jobs it should bid on. If the release re-probe hits a throttled key, the URL check can silently fail too, so keep your verification traffic spaced out as well.