Rate limits and API usage

Two limits apply to every request you make with an API key. A per-second rate limit caps how fast your organization can send requests. A monthly API Calls allowance caps how many successful requests it can make in a calendar month. Both limits cover the whole API. No endpoint has a limit of its own, and there are no credits and no daily limits.

These two limits are separate from feature allowances. Some features also have an allowance of their own, such as credential comparison reports, Attack Surface assessments and Infra search scans. Some resources have a fixed number of slots, such as monitors. Plans and quotas explains those. This page covers the two limits that every API-key request passes.

How the two limits compare

	Per-second rate limit	API Calls allowance
Applies to	Every request	Requests made with an API key
Window	1 second	Calendar month in UTC. Resets at 00:00 UTC on the 1st.
Size	The same for every organization. Read it from `X-RateLimit-Limit`.	Your plan’s API Calls allowance, plus any extra API calls packs
What counts	Every request that passes the authentication, license and plan checks, whatever its status	`2xx` responses only. Any other status is refunded.
When it runs out	`429`. Retry after 1 second.	`429` on every API-key request until the allowance resets

Both limits count per organization, and all of an organization’s API keys share them. A key created for a client workspace counts toward that workspace’s limits, not yours. Dashboard requests have a per-second budget of their own, separate from API-key requests. The sources that a wide search queries draw on the dashboard budget, so heavy dashboard use can make a source report quota_exceeded.

The per-second rate limit

The rate limit allows a fixed number of requests per second for each organization. DarknetSearch sets the number, and it is the same on every plan. Read it from the X-RateLimit-Limit header of a response whose X-RateLimit-Reset is 1.

Every request counts. That includes requests that end in a 4xx or 5xx from the endpoint. Failed requests are not refunded from this count, so a loop of failing requests still uses up the second.
Rejected requests do not count. A request the limit rejects with 429 is not added to the count.
Some refusals come first. A 401, or a 403 for an inactive license or a feature outside your plan, is returned before the limit is checked. It does not count.

When the second is full, the next request returns 429 with Retry-After: 1. The window starts again one second later.

The API Calls allowance

Every request made with an API key draws one unit from your organization’s monthly API Calls allowance. That covers searches, status polls, result pages, downloads and usage reads alike.

Only 2xx responses count. The unit is taken when the request arrives. If the response is any other status, the unit is refunded, so a 400, 404, 409, 429 or 5xx uses no API call.
The window is the calendar month in UTC. The count resets to zero at 00:00 UTC on the 1st. Unused calls do not carry over.
Your plan sets the size. Extra API calls packs, bought in the dashboard, add to the plan’s allowance every month while they are active. A pack counts as soon as its invoice is paid. Plans and quotas explains how allowances and packs work.
Your plan must include API Calls to create a key. See Authentication.

A call to a metered feature, such as starting an Infra search scan, also uses one unit of that feature’s allowance. The two are counted separately. If the feature’s allowance is spent, the 429 is not a 2xx, so the API call is refunded. To see how much of the month’s allowance is left, open Manage → Usage in the dashboard. Org Admins, System Admins and System Users can open it. Plans and quotas describes the page. The X-RateLimit-* headers also switch to the API Calls allowance when it is close to running out.

Read the X-RateLimit headers

Responses carry three headers that describe one of your limits:

Header	Meaning
`X-RateLimit-Limit`	The size of the limit: requests per second, or your monthly API Calls allowance
`X-RateLimit-Remaining`	Requests left in the current window
`X-RateLimit-Reset`	Seconds until the window resets. `1` means the per-second window.

The headers describe whichever limit has the fewest requests left. Usually that is the per-second window, and X-RateLimit-Reset reads 1. When fewer API calls remain in the month than requests remain in the current second, the headers switch to the API Calls allowance:

HTTP/1.1 200 OK
X-RateLimit-Limit: 5000
X-RateLimit-Remaining: 2
X-RateLimit-Reset: 333312

Here the organization has 2 API calls left, and the allowance resets in 333,312 seconds (about 3 days and 21 hours), at 00:00 UTC on the 1st. The headers appear on every response that reached the limit check: 2xx, endpoint errors and the 429 from the limit itself. On that 429 they describe the limit you hit. They are absent on 401 and on the 403 refusals that come before the limit check.

When you exceed a limit

Both limits answer with 429 Too Many Requests and the same message. The body tells you which one you hit. Per-second rate limit. Wait one second, then retry.

HTTP/1.1 429 Too Many Requests
Retry-After: 1

{
  "message": "Rate limit exceeded",
  "retry_after_seconds": 1
}

API Calls allowance. The body adds limit, remaining and reset_at. Retry-After and retry_after_seconds count down to the reset, which can be weeks away.

HTTP/1.1 429 Too Many Requests
Retry-After: 2037599

{
  "message": "Rate limit exceeded",
  "retry_after_seconds": 2037599,
  "limit": 5000,
  "remaining": 0,
  "reset_at": "2026-10-31T23:59:59.250000+00:00"
}

limit is your monthly allowance, packs included. reset_at is the moment the allowance resets, 00:00 UTC on the 1st. The timestamp can read a fraction of a second earlier. Every request made with any of your organization’s keys gets this response until then, unless an extra API calls pack raises the allowance first. A third 429 comes from a feature allowance, not from the rate limits on this page. Tell them apart by the body:

The `429` body has	Cause	What to do
`"message": "Rate limit exceeded"` and `"retry_after_seconds": 1`	Per-second rate limit	Wait for `Retry-After`, then retry
`"message": "Rate limit exceeded"` with `limit`, `remaining` and `reset_at`	API Calls allowance used up	Queue API-key requests until `reset_at`
`detail`, `resource`, `period` and `limit`	A feature allowance used up, such as `infra_search_scan`	Do not retry. See Plans and quotas.

A feature allowance 429 has no Retry-After header. Any other 429 body comes from the service behind the endpoint, and that endpoint’s guide describes it. Errors lists every error the API returns.

Review past API activity

get_api_call_usage returns your organization’s request counts for a range of months, split by day and by HTTP status code. Use it to see trends, error rates and 429 counts over time. Availability: every plan with a license in force. Cost: 1 unit of your monthly API Calls allowance, like any request. The unit is refunded if the response is not a 2xx. Pass the first and last month as YYYYMM. Both are required, and the range is inclusive.

curl "https://client-api.leak.center/api/service/get_api_call_usage/?from_year_month=202609&to_year_month=202610" \
  -H "X-API-Key: YOUR_API_KEY"

{
  "months": [
    {
      "month": "2026-10",
      "calls_per_status": { "200": 1209, "201": 25, "400": 2, "429": 3 },
      "total": 1239,
      "detail": [
        { "date": "2026-10-01", "calls_per_status": { "200": 611, "201": 14, "400": 2 } },
        { "date": "2026-10-02", "calls_per_status": { "200": 598, "201": 11, "429": 3 } }
      ]
    }
  ]
}

This organization made its first requests on 1 October, so September has no records and is left out.

Field	Meaning
`months[].month`	The month, as `YYYY-MM`
`months[].calls_per_status`	Requests in the month per HTTP status code. Keys are status codes as strings.
`months[].total`	The sum of `calls_per_status`
`months[].detail[]`	One entry per day with requests: `date` as `YYYY-MM-DD` and that day’s `calls_per_status`

It counts all of your organization’s traffic. API-key requests and dashboard requests are counted together, with every status code, 403 and 429 included. Requests rejected with 401 are not recorded. The 2xx count can therefore be higher than the API Calls you used.
It is activity history, not your balance. For the API Calls left this month, see Manage → Usage in the dashboard, as described in The API Calls allowance. The X-RateLimit-* headers switch to the allowance only when it is almost used up.
It updates once a day. The most recent day can be missing or incomplete until the next daily update.
Days are counted in UTC. Months with no recorded requests are left out of months.

Errors this endpoint can return:

Status	Body	Cause
`400`	`{"from_year_month": ["Expected a month in YYYYMM format."]}`	A month is not six digits in `YYYYMM` format. The key names the parameter.
`400`	`{"to_year_month": ["This field is required."]}`	A parameter is missing
`400`	`{"non_field_errors": ["from_year_month cannot be after to_year_month."]}`	The range runs backwards
`403`	`{"detail": "Your license is not active."}`	Your organization has no license in force
`429`	`{"message": "Rate limit exceeded", ...}`	A rate limit on this page. See When you exceed a limit.

It has no plan feature check, no feature allowance and no capacity limit.

Best practices

Pace requests below the per-second limit

All of your organization’s keys share one per-second budget. Send requests from one shared queue rather than from many workers that each send at full speed. When X-RateLimit-Remaining reaches 0 and X-RateLimit-Reset reads 1, pause until the next second.

Back off on a per-second 429

Wait the Retry-After seconds, then retry the same request. If the next attempt also returns 429, double the wait each time up to a few seconds, and add a little random delay so parallel workers do not retry in step.

Stop on an allowance 429

A 429 with reset_at means the month’s API Calls are used up. Queue the work until reset_at instead of retrying in a loop. A 429 with resource means a feature allowance is used up. Retrying cannot succeed until the allowance resets or a pack is added.

Poll asynchronous jobs at a steady interval

Each status poll that returns 200 uses one API call. Poll every 10 to 30 seconds, or at the interval the job’s guide recommends, and stop at the first terminal status. A job polled every 10 seconds for 20 minutes uses 120 API calls.

Budget the month

Count every call a workflow makes. A search that creates a job, polls 30 times and reads 5 result pages uses 36 API calls. Request larger pages where an endpoint allows it, since one page is one call. Cache results and reuse them instead of repeating the same search.

Watch usage before it runs out

Read X-RateLimit-Reset on your responses. When it reads more than 1, the API Calls allowance is now the tighter limit and X-RateLimit-Remaining is the number of calls left this month. Use get_api_call_usage to review trends and error rates over past months.

Endpoints

Action	Endpoint
Review request counts per month, day and status code	`GET /api/service/get_api_call_usage/`

Get started

Search

Leaked credentials

Assess & report

Monitors

Domain monitoring

Downloads & exports

Changelog

Rate limits and API usage

How the two limits compare

The per-second rate limit

The API Calls allowance

Read the X-RateLimit headers

When you exceed a limit

Review past API activity

Best practices

Endpoints

​How the two limits compare

​The per-second rate limit

​The API Calls allowance

​Read the X-RateLimit headers

​When you exceed a limit

​Review past API activity

​Best practices

​Endpoints

How the two limits compare

The per-second rate limit

The API Calls allowance

Read the X-RateLimit headers

When you exceed a limit

Review past API activity

Best practices

Endpoints