Skip to main content
HTTP 429 · type rate_limit. The account is already running as many sessions/extractions as it’s allowed to have in flight (new accounts start at 1). Expensive work is limited by concurrency, not requests-per-minute — a run holds real browsers and real model spend for minutes, so the cap is on simultaneous runs. Nothing was charged.

The shape

limit is the account’s cap; in_flight is what’s running now. Retry-After is an estimate, not a promise — runs take minutes and finish when they finish.

How to fix

  • Find what’s running: GET /v1/sessions?status=running. Wait for its terminal (webhook, long-poll, or stream), or POST …/stop it if it’s no longer wanted.
  • Queue on your side: serialize run creation behind the session.answered / extraction.delivered webhook instead of retrying blind.
  • Note a batch extraction (urls[]) occupies concurrency per URL as passes dispatch — a 50-URL batch on a concurrency-1 account is a queue, not a parallel sweep.
  • Need real parallelism? Concurrency limits are raised per account — contact us; your current limit is visible in GET /v1/me (concurrency_limit).

Reproduce it

Requires a run genuinely in flight, so this one costs a real (small) run: