> ## Documentation Index
> Fetch the complete documentation index at: https://docs.topograph.co/llms.txt
> Use this file to discover all available pages before exploring further.

# Concurrency & Backfills

> Manage parallel company requests and leave capacity for your live operations

Your account has a shared limit on company requests being processed at the same time. The default is **40 in-flight slots**. Contact support if you need a higher limit for a backfill or sustained traffic.

## What counts toward the limit

A standard company request uses one slot while processing. An ownership graph request uses five slots. Requests from your account share the same capacity, including onboarding and verification requests.

An HTTP response does not necessarily free a slot: a company request can return with data still `in_progress`. Track outstanding work using [webhooks](/guides/webhooks) or retrieve the existing request's status. Completed requests release capacity. Work paused while waiting for external action does not hold capacity during that wait.

Development-mode requests do not consume these slots. Search and polling existing results do not start company retrievals and do not consume additional slots. API rate limits apply separately.

## Read your available capacity

Company request responses expose these headers when concurrency usage can be evaluated:

| Header                    | Meaning                                                                     |
| ------------------------- | --------------------------------------------------------------------------- |
| `X-Concurrency-Limit`     | Your account's current slot limit                                           |
| `X-Concurrency-Remaining` | Available slots at the time of the check, before the new request is counted |

These values are a snapshot, not reserved capacity. Other requests can consume slots before your next call. Keep a local limit on outstanding work even when these headers are absent.

Concurrency is separate from requests per minute. The `X-RateLimit-*` headers describe the latter; raising your concurrency limit does not raise your per-minute limit.

## Handle a concurrency rejection

When your account is at capacity, a new company request receives HTTP `429` before processing starts. The response includes `Retry-After` in seconds and a body like this:

```json theme={null}
{
  "statusCode": 429,
  "code": "too_many_requests",
  "limit": "concurrency",
  "limitValue": 40,
  "active": 40,
  "retryAfter": 12,
  "message": "Concurrency limit reached: your account is using 40 of 40 in-flight request slots. Wait for requests to complete and retry with backoff, or contact support to raise your limit."
}
```

Wait at least the `Retry-After` duration before retrying. Add a small random delay so queued requests do not all retry together. If the next attempt is also rejected, continue backing off. Use `limit: "concurrency"` to identify a concurrency rejection; HTTP `429` can also indicate a per-minute rate limit.

## Run a backfill alongside live traffic

1. Use a queue with a fixed cap on outstanding work. Sending a batch every ten minutes does not control concurrency if earlier batches are still processing.
2. Reserve capacity for normal operations. For example, with an 80-slot account limit, cap a backfill of standard company requests at 20 outstanding requests to leave headroom for live traffic.
3. Count graph requests as five slots when setting your backfill budget.
4. Wait for requests to finish before taking more work from the queue. Receiving the initial HTTP response is not enough.
5. Increase volume gradually while watching completion times and `429` responses.

For a planned backfill, share expected volumes by country and your schedule with support. Agree when to review any temporary limit increase after the backfill finishes.