## TL;DR
The 402 means more requests are in flight at once than the plan allows. Count actual concurrent requests (not threads, in-flight HTTP calls), then lower concurrency to fit or raise the plan. Async code routinely runs more concurrent requests than the author thinks, which is why the limit surprises people.

```text
zenrows 402 concurrency limit exceeded
```

## Use this when
- Parallel scraping 402s while single requests succeed.
- The error appears under load and clears when idle.
- You recently raised concurrency or switched to async.

## Not for this skill when
- The error is 401. That is the API key.
- Sequential requests also 402. Then the account itself is the problem.

## Steps
1. Measure real concurrency: log how many requests are in flight at peak. Verify: the number exceeds the plan limit.
2. Cap concurrency in code below the plan limit with headroom (limit minus two). Verify: the 402 stops.
3. Check for accidental fan-out: retries, redirects, and pagination that multiply in-flight requests. Verify: the measured number matches what you configured.
4. Queue excess work instead of firing it: a semaphore or worker pool. Verify: throughput is smooth instead of spiky.
5. If the capped throughput is too slow for the workload, upgrade the plan. Verify: the new limit covers measured peak concurrency.

## Variant phrasings
### zenrows 402 concurrency
The short search, same measurement-first fix.
### zenrows too many concurrent requests
Wording variant, points at step 1.
### zenrows parallel requests failed
Symptom phrasing, lands on the semaphore fix.

Compatibility: ZenRows API. Concurrency limits are per plan and enforced on in-flight requests.

## Why it happens
Concurrency limits count requests being processed right now, not requests per minute. Async and threaded code easily holds dozens of requests in flight while the author thinks in terms of "ten threads". Retries make it worse: a slow target holds requests open longer, so the same thread count produces higher in-flight numbers.

## Edge cases / pitfalls
- A semaphore around request issue is not enough if retries bypass it. Wrap the whole attempt including retries.
- Slow targets inflate in-flight counts. Timeouts that are too generous raise effective concurrency.
- Do not split work across multiple keys to dodge the limit. That is against the terms.
- The 402 is per account, so one runaway script 402s every other script on the key.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_BWSrh8HAm6Z19fkXg2Efyg