Summarize an organization's credential exposure

The organization analytics answer “how exposed are we?” in numbers. How many credentials for your domain leaked in the past 30 days? Which addresses appear in the most leaks? How many leaked passwords are shorter than eight characters? Which of your subdomains show up in stealer logs? In the API reference these endpoints sit under the Leaks Analysis tag. Every figure covers your organization’s own domain, the domain that get_direct_org_info returns, within one analysis window: the last 7, 30 or 365 days. An API key always reads its own organization’s figures. Clients whose assets you register in your own organization are not covered: to report on a client’s domain here, the client needs a client workspace of its own, read with that workspace’s key. See Client organizations. Each call answers in the same response. There is no job to start and nothing to poll. One endpoint, leak_type_analysis, works differently: it runs a live search for the domain and dates you send.

Availability and cost

Availability: every plan with a license in force. None of these endpoints checks a plan feature. Cost: no feature allowance. Each call made with an API key uses 1 unit of your monthly API Calls allowance, refunded if the response is not 2xx. Every call also counts toward the per-second rate limit. See Rate limits. Without a license in force, every endpoint on this page returns 403:

{
  "detail": "Your license is not active."
}

These endpoints never return the plan-feature 403, a feature-allowance 429 (detail, resource, period, limit) or a capacity 409. The per-second rate limit 429 and the API Calls allowance 429 still apply. See When you exceed a limit. Plans and quotas explains license states.

How the figures are built

Precomputed once a week. The figures are not computed when you call. DarknetSearch recomputes the figures of every organization with a license in force once a week, for all three windows at once. A read returns the last computed set. The numbers change about once a week, so there is no need to poll them.
Counted back from the last refresh. A window covers the 7, 30 or 365 days before the last weekly refresh, not the days before your call.
Indexed date, not theft date. The breach feed, the subdomain list, the risky-users chart and the password strength figures select leak records by the date DarknetSearch indexed them, not by when the credentials were stolen.
Empty until the first run. For a new organization, lists stay empty and counts stay 0 until its first computation finishes. Before the analytics service knows the organization at all, reads return 404. See Errors.

For current data on your domain, use Filtered credentials or the ULP feed. They search when you call.

Set the analysis window

The window is one setting for your whole organization. It is not a parameter of each read. Every API key of your organization reads through the same window, and the window stays set until someone changes it.

`current_date_range`	Figures cover
`7D`	The 7 days before the last refresh
`30D`	The 30 days before the last refresh
`365D`	The 365 days before the last refresh

Set it with update_current_date_range:

curl https://client-api.leak.center/api/service/update_current_date_range/ \
  -X POST \
  -H "X-API-Key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"current_date_range": "30D"}'

{
  "current_date_range": "30D"
}

Read it with get_current_date_range. The response has the same shape.

curl https://client-api.leak.center/api/service/get_current_date_range/ \
  -H "X-API-Key: YOUR_API_KEY"

All three windows are computed ahead of time, so a switch takes effect at once. The next read returns the figures for the new window.

Set the window at the start of every run, then read. Another integration in your organization may have changed it since your last run. Store the window next to the figures you save.

Any value other than 7D, 30D or 365D returns 400:

{
  "current_date_range": ["\"90D\" is not a valid choice."]
}

Read a summary in one run

Set the window

Send update_current_date_range with the window you want, as shown above.

Read the figures

Each read is a plain GET with no required parameters.

for op in leaked_credentials_stats top_risky_users top_risky_passwords \
          risky_users_chart_stats password_strength_analysis \
          external_service_login_stealer_logs internal_service_third_party_login \
          top_affected_subdomains_stealer_logs; do
  curl -s "https://client-api.leak.center/api/service/$op/" \
    -H "X-API-Key: YOUR_API_KEY" > "$op.json"
done

Page through the breach rows

Read account_breaches page by page until you have count rows.

A full summary takes ten calls or more, depending on how many breach pages you read. Each call uses 1 unit of your API Calls allowance.

Credential totals

leaked_credentials_stats counts the leaked credentials for your domain in the window.

{
  "total_number": 2418,
  "unique_number": 1530,
  "total_found_in_combo_lists": 1204,
  "unique_found_in_combo_lists": 811,
  "total_originating_stealer_logs": 356,
  "unique_originating_stealer_logs": 214
}

Field	Counts
`total_number`	Every leaked credential for your domain in the window
`unique_number`	The same credentials, each counted once
`total_found_in_combo_lists`	Credentials found in combolists
`unique_found_in_combo_lists`	The same, each counted once
`total_originating_stealer_logs`	Credentials that come from stealer logs
`unique_originating_stealer_logs`	The same, each counted once

unique_number can be 0 while total_number is not. That means the unique count was not available for that window, not that no credentials leaked.

The riskiest users and passwords

Top risky users

top_risky_users returns up to three users with the most leaked credentials in the window, highest number_of_leaks first.

{
  "results": [
    { "username": "jdoe@acme.com", "number_of_leaks": 14, "unique_count": 9 },
    { "username": "asmith@acme.com", "number_of_leaks": 11, "unique_count": 7 },
    { "username": "mgarcia@acme.com", "number_of_leaks": 8, "unique_count": 8 }
  ]
}

username: the leaked login, usually an address on your domain.
number_of_leaks: how many leaked credentials name this user.
unique_count: the same count with duplicates filtered out.

Top risky passwords

top_risky_passwords returns up to three leaked username and password pairs that appear most often. The fields match the user list, plus password.

{
  "results": [
    { "username": "jdoe@acme.com", "password": "Summer2026!", "number_of_leaks": 6, "unique_count": 4 },
    { "username": "helpdesk@acme.com", "password": "Acme2024!", "number_of_leaks": 9, "unique_count": 5 }
  ]
}

The rows are not sorted by count. Sort them by number_of_leaks yourself before you rank them.

The response carries passwords in clear text, and so does account_breaches. Keep these responses out of logs and tickets.

How leaks spread across users

risky_users_chart_stats shows whether exposure is concentrated on a few people or spread across many. It counts the email addresses on your domain found in leak records indexed in the window. For each address, it counts the distinct leaked files that address appears in. Then it groups the addresses by that number.

{
  "results": [
    { "number_of_leaks": 6, "number_of_users_per_leak": 1 },
    { "number_of_leaks": 3, "number_of_users_per_leak": 4 },
    { "number_of_leaks": 2, "number_of_users_per_leak": 11 },
    { "number_of_leaks": 1, "number_of_users_per_leak": 87 }
  ]
}

number_of_leaks: a number of distinct leaked files.
number_of_users_per_leak: how many addresses appear in exactly that many files.

Read each row as “number_of_users_per_leak addresses appear in number_of_leaks files each.” Above, 87 addresses appear in one file each, and one address appears in six. The rows come highest number_of_leaks first. Their number_of_users_per_leak values add up to the number of distinct addresses found: 103 here.

Password strength

password_strength_analysis tests the leaked passwords of your domain’s email addresses against a basic policy: at least 8 characters, 1 uppercase letter, 1 digit and 1 special character.

{
  "total_number": 412,
  "not_meet_minlength": 61,
  "not_contain_uppercase": 248,
  "not_contain_digit": 97,
  "not_contain_special": 301
}

Field	Counts
`total_number`	Clear-text passwords tested
`not_meet_minlength`	Passwords shorter than 8 characters
`not_contain_uppercase`	Passwords with no uppercase letter
`not_contain_digit`	Passwords with no digit
`not_contain_special`	Passwords with no special character

How to read the counts:

They overlap. A password can fail several rules, so the four counts do not add up to total_number. Divide each by total_number for a share: 248 of 412 here, or 60%, have no uppercase letter.
Only clear text is tested. Passwords come from leaks tagged password or hash. A value longer than 12 characters that is not all letters is treated as a hash and skipped.
Records, not people. The same password counts once for every leak record it appears in.

Where credentials were used

Three lists show the services and hosts that appear in your domain’s leaked credentials. They share one response shape and the same paging:

{
  "count": 6,
  "results": [ ... ]
}

count is the length of the whole list. results holds one page of it.

Parameter	Values
`page`	`1` or more. Counting starts at `1`. The default is `1`.
`size`	`5` to `100` rows. The default is `10`.
`name` or `sub_domain`	Optional. Keeps rows whose name contains the value, ignoring case.

A page past the end of the list returns 404 with {"detail": "Invalid page."}. Stop when you have read count rows.

External services

external_service_login_stealer_logs lists services outside your domain where stealer logs captured your people’s credentials, most frequent first. Filter by name.

curl -G https://client-api.leak.center/api/service/external_service_login_stealer_logs/ \
  -H "X-API-Key: YOUR_API_KEY" \
  --data-urlencode 'size=20'

{
  "count": 14,
  "results": [
    { "name": "portal.acme-login.com", "count": 23 },
    { "name": "mail.acme-login.com", "count": 9 }
  ]
}

name: the service’s server name.
count: how many of the window’s leaked credentials were for that service.

To list matching accounts, run Filtered credentials with Employee Logins on External Services (filter_id 2). Filtered credentials is not limited to the analysis window, so its results do not match these counts one to one.

Your services, used by outsiders

internal_service_third_party_login lists services on your own domain that appear in leaked credentials with third-party logins, most frequent first. Filter by name.

{
  "count": 3,
  "results": [
    { "name": "vpn.acme.com", "count": 12 },
    { "name": "intranet.acme.com", "count": 5 }
  ]
}

The fields match the external list. To list matching accounts, run Filtered credentials with Third Party Logins (filter_id 7): logins to servers on your domain whose username is an email address on another domain. Filtered credentials is not limited to the analysis window.

Subdomains in stealer logs

top_affected_subdomains_stealer_logs lists the host names under your domain that appear in stealer logs indexed in the window, most frequent first. Filter by sub_domain.

curl -G https://client-api.leak.center/api/service/top_affected_subdomains_stealer_logs/ \
  -H "X-API-Key: YOUR_API_KEY" \
  --data-urlencode 'sub_domain=vpn'

{
  "count": 1,
  "results": [
    { "sub_domain": "vpn.acme.com", "leaks_number": 31 }
  ]
}

sub_domain: a host name under your domain, such as vpn.acme.com. The bare domain acme.com is not listed.
leaks_number: how many stealer-log records name this host. Each record counts once, for the first host under your domain it names. Records with the same content count once.

The count stops after the first 2,000 host mentions in the window. To read the captures themselves, search Stealer logs for the host name.

List the leaked accounts

account_breaches is the row-level feed behind the figures: one row per leaked credential line for your domain in the window. It reads leak records indexed in the window that come from leaks tagged account. From each line that mentions your domain, it extracts the login, password and website.

Parameter	Values
`page`	`1` or more. Counting starts at `1`. The default is `1`.
`size`	`5` to `100` rows. The default is `10`.
`login`	Keeps rows whose login contains the value, ignoring case
`password`	Keeps rows whose password contains the value. Case matters.
`website`	Keeps rows whose website contains the value, ignoring case
`leak_source`	Keeps rows whose source contains the value, ignoring case
`leak_date_after`	`YYYY-MM-DD`. Keeps rows indexed on or after this date.
`leak_date_before`	`YYYY-MM-DD`. Keeps rows indexed on or before this date.

The filters narrow the rows inside the current window. They cannot reach outside it. To read rows older than the window, set a longer window first.

curl -G https://client-api.leak.center/api/service/account_breaches/ \
  -H "X-API-Key: YOUR_API_KEY" \
  --data-urlencode 'website=vpn.acme.com' \
  --data-urlencode 'size=50'

{
  "count": 2,
  "results": [
    {
      "leak_date": "2026-09-28T04:12:51Z",
      "login": "jdoe@acme.com",
      "password": "Summer2026!",
      "leak_source": "darknet",
      "website": "https://vpn.acme.com/login"
    },
    {
      "leak_date": "2026-09-14T22:40:03Z",
      "login": "asmith@acme.com",
      "password": null,
      "leak_source": "darknet",
      "website": "vpn.acme.com"
    }
  ]
}

leak_date: when DarknetSearch indexed the record, in UTC. It is not the date of the breach.
login, password, website: the values extracted from the leaked line. Each is null when the line does not hold it, and each is cut at 200 characters.
leak_source: where the leak was found, such as darknet.

Rows come most recently indexed first. They are not deduplicated, so the same credential can appear in more than one row. A page past the end returns 404 with {"detail": "Invalid page."}. To read the full record around a row, search Raw Data for the login.

Classify leaks as personal or business

leak_type_analysis splits the leak records that mention a domain by the kind of leak they come from: personal accounts, business accounts, both, or neither. Unlike the other endpoints, it runs a live search when you call it. It ignores the analysis window and uses the dates you send.

Field	Values
`domain`	Required. The domain to classify, such as `acme.com`. Usually your organization’s domain; any domain is accepted.
`start_date`	Optional. `YYYY-MM-DD`. Counts records indexed on or after this date.
`end_date`	Optional. `YYYY-MM-DD`. Counts records indexed on or before this date.

Leave out both dates to count every indexed record. start_date cannot be after end_date.

curl https://client-api.leak.center/api/service/leak_type_analysis/ \
  -X POST \
  -H "X-API-Key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"domain": "acme.com", "start_date": "2026-01-01", "end_date": "2026-06-30"}'

{
  "total_leaks": 5210,
  "private_only": 1830,
  "private_only_percentage": 35.12,
  "business_only": 2214,
  "business_only_percentage": 42.5,
  "both_private_and_business": 640,
  "both_percentage": 12.28,
  "unclassified": 526,
  "unclassified_percentage": 10.1
}

The analysis groups the matching records by leak, then sorts each leak into one bucket by its tags. private marks a leak of personal accounts and business a leak of business accounts.

Field	Records from leaks tagged
`private_only`	`private` and not `business`
`business_only`	`business` and not `private`
`both_private_and_business`	Both `private` and `business`
`unclassified`	Neither, or no tags at all

total_leaks counts records, not leaks. It is the number of matching records across all leaks. The four buckets add up to it.
Each percentage is the bucket’s share of total_leaks, rounded to two decimals. All four are 0.0 when total_leaks is 0.

To leave a date open, omit the field. Sending null or an empty string returns 400.

The live search takes longer on a domain with many leaks. When it runs past the API’s wait, 30 seconds by default, the call returns 504. Narrow the date range and retry. The call is refunded.

Errors

These errors are specific to the endpoints on this page. Handle API errors lists the ones every endpoint shares, such as 401 and the rate-limit 429.

Status	Endpoint	Body	Cause
`400`	`update_current_date_range`	`{"current_date_range": ["\"90D\" is not a valid choice."]}`	The window is not `7D`, `30D` or `365D`.
`400`	Every `GET` except `get_current_date_range`	Field errors, such as `{"size": ["Ensure this value is less than or equal to 100."]}`	`page` is below `1` or `size` is outside 5 to 100. On `account_breaches`, also a date that is not `YYYY-MM-DD`.
`400`	`leak_type_analysis`	`{"domain": ["This field is required."]}`, `{"start_date": ["start_date must be in YYYY-MM-DD format"]}` or `{"non_field_errors": ["start_date cannot be after end_date"]}`	The body is incomplete or a date is invalid. A `null` or empty date also returns `400`.
`400`	`leak_type_analysis`	`{"error": "Organization is invalid or deactivated"}`	The analytics service has not picked up your organization’s license yet. It syncs organizations every hour. Retry later.
`404`	`update_current_date_range`	`{"error": "Organization is invalid or deactivated"}`	The same cause
`404`	Any `GET`	`{"detail": "No Organization matches the given query."}`	The analytics service does not know your organization yet. It syncs organizations every hour. Retry later.
`404`	The paged lists and `account_breaches`	`{"detail": "Invalid page."}`	`page` is past the end of the list. Stop paging.
`502`	Any	`{"detail": "The requested service is temporarily unavailable."}`	The analytics service or the live search failed. Retry with backoff.
`502`	Any	`{"message": "An unexpected error occurred. Please try again later or contact support."}`	The analytics service answered with data the API could not validate. Retry later. Branch on the status code, not the body.
`504`	Any, usually `leak_type_analysis`	`{"detail": "The requested service timed out."}`	The service did not answer in time. For `leak_type_analysis`, narrow the date range.

You want	Use
Every exposed account on a domain you own, deduplicated and risk-scored, searched when you call	Filtered credentials
One login, password or website looked up live, on any domain	The ULP feed
The raw leaked record around a breach row	Raw Data
The whole capture from an infected machine	Stealer logs
Leaked credentials compared across several domains, as a report	Credential comparison report

Endpoints

Action	Endpoint
Set the analysis window	`POST /api/service/update_current_date_range/`
Read the analysis window	`GET /api/service/get_current_date_range/`
Count leaked credentials	`GET /api/service/leaked_credentials_stats/`
List the top risky users	`GET /api/service/top_risky_users/`
List the top risky passwords	`GET /api/service/top_risky_passwords/`
Chart how leaks spread across users	`GET /api/service/risky_users_chart_stats/`
Test leaked passwords against a basic policy	`GET /api/service/password_strength_analysis/`
List external services in stealer-log credentials	`GET /api/service/external_service_login_stealer_logs/`
List your services used with third-party logins	`GET /api/service/internal_service_third_party_login/`
List your subdomains in stealer logs	`GET /api/service/top_affected_subdomains_stealer_logs/`
List the leaked accounts	`GET /api/service/account_breaches/`
Classify leaks as personal or business	`POST /api/service/leak_type_analysis/`

Get started

Search

Leaked credentials

Assess & report

Monitors

Domain monitoring

Downloads & exports

Changelog

Summarize an organization's credential exposure

Availability and cost

How the figures are built

Set the analysis window

Read a summary in one run

Credential totals

The riskiest users and passwords

Top risky users

Top risky passwords

How leaks spread across users

Password strength

Where credentials were used

External services

Your services, used by outsiders

Subdomains in stealer logs

List the leaked accounts

Classify leaks as personal or business

Errors

Endpoints

​Availability and cost

​How the figures are built

​Set the analysis window

​Read a summary in one run

​Credential totals

​The riskiest users and passwords

​Top risky users

​Top risky passwords

​How leaks spread across users

​Password strength

​Where credentials were used

​External services

​Your services, used by outsiders

​Subdomains in stealer logs

​List the leaked accounts

​Classify leaks as personal or business

​Errors

​Related guides

​Endpoints

Availability and cost

How the figures are built

Set the analysis window

Read a summary in one run

Credential totals

The riskiest users and passwords

Top risky users

Top risky passwords

How leaks spread across users

Password strength

Where credentials were used

External services

Your services, used by outsiders

Subdomains in stealer logs

List the leaked accounts

Classify leaks as personal or business

Errors

Related guides

Endpoints