Check whether a password has leaked in a known data breach.
Password Breach Checker tells you whether a password appears in the Pwned Passwords corpus of passwords exposed in data breaches. Send the password or its SHA-1 hash and get a breached flag. Paid plans add how many times it was seen and a risk level.
Try it — live request, no key required
No key required to try it. Get a key to use it in your app.
{
"status": "ok",
"error": null,
"data": {
"breached": true,
"breachCount": 2266543,
"riskLevel": "critical",
"inputType": "password",
"hashPrefix": "CBFDA"
}
}
About the Password Breach Checker API
The password is hashed with SHA-1 on our side and only the first 5 characters of the hash are sent to the Pwned Passwords range API, with response padding on, so the password itself never leaves the request. It is not logged, stored or returned. You can also send the SHA-1 yourself so the plain password never reaches us.
What people use it for
- Sign-Up and Password Change
- Reject or warn on passwords that have appeared in breaches when a user creates an account or changes their password, as NIST SP 800-63B recommends.
- Login Risk Scoring
- Flag accounts whose current password is known to be breached and prompt a reset before credential stuffing finds them.
- Password Audits
- Check stored SHA-1 hashes from a legacy system against the breach corpus without handling plain passwords.
- Password Managers
- Mark saved passwords that have leaked so users know which ones to change first.
Ways to call it
One endpoint, many ways in — REST with JSON, XML, YAML and CSV, plus GraphQL and an MCP interface for AI agents.
- JSON
- Default REST response
- XML
- Markup format
- YAML
- Human-readable
- CSV
- Tabular export
- GraphQL
- Query language
- MCP
- For AI agents
Other ways to use Password Breach Checker
Same data, same APIVerve account, same credit balance — one key works on all of them.
How many password checks does the Starter plan cover?
What does the Free plan return?
Is my password sent to a third party?
Can I check a hash instead of the plain password?
How are the risk levels defined?
Request parameters — POST /v1/passwordbreach
Sent as JSON in the request body. Premium parameters are accepted on every plan but only take effect on plans that include them. Anything not listed here is dropped rather than passed through.
Optional
| Parameter | Type | Example | Description |
|---|---|---|---|
passwordOptional | string | password123 | The password to check. Hashed on receipt and never stored. Send this or hash length 0-1024 |
hashOptional | string | 5BAA61E4C9B93F3F0682250B6CF8331B7EE68FD8 | The 40-character hex SHA-1 of the password, instead of the password itself |
curl -X POST "https://api.apiverve.com/v1/passwordbreach" \
-H "x-api-key: YOUR_API_KEY" \
-H "Content-Type: application/json" \
-d '{"password":"password123","hash":"value"}'Authentication
Send your key in the x-api-key header. That is the only auth step — no token exchange, and no per-endpoint scope to configure.
| Header | When | Value |
|---|---|---|
x-api-keyRequired | Every request | Your API key. Header names are case-insensitive, so X-API-Key is the same header. |
AuthorizationAlternate | Instead of the above | Bearer <key> — for clients that only expose bearer auth. Resolves to the same account and the same billing. |
content-typeRequired | POST body | application/json |
A 401 means the key is missing, invalid or expired. A 403 means the key is valid but not permitted here — blocked by a key restriction or an IP allow-list. Running out of credits is a 429.
Response — POST /v1/passwordbreach
Every APIVerve endpoint returns the same three top-level keys, so one response handler covers your whole integration: status, error and data. Only data changes shape.
{
"status": "ok",
"error": null,
"data": {
"breached": true,
"breachCount": 2266543,
"riskLevel": "critical",
"inputType": "password",
"hashPrefix": "CBFDA"
}
}
Response fields
Paths are relative to data. Premium fields are absent rather than zeroed on plans that do not include them, so check for presence instead of comparing to 0.
| Field | Type | Example | Description |
|---|---|---|---|
breached | boolean | true | True when the password appears in the breach corpus |
breachCountPremium | number | 2266543 | Number of times the password appears in the breach corpus |
riskLevelPremium | string | "critical" | Exposure bracket: none, low (1-9), medium (10-999), high (1,000-99,999) or critical (100,000+) |
inputType | string | "password" | Whether a password or a hash was checked |
hashPrefix | string | "CBFDA" | The 5-character SHA-1 prefix that was sent to the range API |
Response headers
Every response carries your balance, so your own code always knows where it stands without polling anything. All four are exposed to browsers through CORS.
| Header | What it carries |
|---|---|
x-api-remaining-credits | Credits left in the current cycle |
x-api-credits-used | Credits spent in the current cycle |
x-api-max-credits | The allowance for the cycle |
x-api-version | Version of the endpoint that answered |
Errors
Read the HTTP status first, then error for the specific reason. The body names the parameter that has to change.
| Status | Meaning | What to do |
|---|---|---|
400 | Input was rejected | Read error; it names the parameter that has to change. |
401 | Key missing or invalid | Check the header name and the key value. |
403 | Key valid, but not permitted here | A key restriction or an IP allow-list — never a bad key. |
429 | Rate limited, or out of credits | Read error to tell them apart, then back off or top up. |
What a call costs — 5 credits per call
Credits are shared across every APIVerve API — one balance, one key, one bill. Failed requests never count against it, so a rejected input costs nothing.
| Plan | Per month | Credits | Password Breach Checker calls | Per 1,000 calls |
|---|---|---|---|---|
| Free | Free | 200 | 40 | Free |
| Starter | $29.99 | 200,000 | 40,000 | $0.75 |
| Pro | $99.99 | 1,000,000 | 200,000 | $0.50 |
| Mega | $299.99 | 4,000,000 | 800,000 | $0.37 |
Calls are what the credits buy at this API's rate — spend them here, on any of the other APIs, or across both. Nothing is reserved per endpoint.
Call it from cURL — POST /v1/passwordbreach
No SDK to install — this is a plain HTTPS call to /v1/passwordbreach with your key in the x-api-key header. Swap in a real key and it runs as-is.
curl "https://api.apiverve.com/v1/passwordbreach" \
-H "x-api-key: YOUR_API_KEY"Resources
Call it from Node.js — POST /v1/passwordbreach
No SDK to install — this is a plain HTTPS call to /v1/passwordbreach with your key in the x-api-key header. Swap in a real key and it runs as-is.
const res = await fetch("https://api.apiverve.com/v1/passwordbreach", {
headers: { "x-api-key": "YOUR_API_KEY" },
});
const { data } = await res.json();
console.log(data);Resources
Call it from Python — POST /v1/passwordbreach
No SDK to install — this is a plain HTTPS call to /v1/passwordbreach with your key in the x-api-key header. Swap in a real key and it runs as-is.
import requests
res = requests.get(
"https://api.apiverve.com/v1/passwordbreach",
headers={"x-api-key": "YOUR_API_KEY"},
)
print(res.json()["data"])Resources
Call it from C# / .NET — POST /v1/passwordbreach
No SDK to install — this is a plain HTTPS call to /v1/passwordbreach with your key in the x-api-key header. Swap in a real key and it runs as-is.
using var client = new HttpClient();
client.DefaultRequestHeaders.Add("x-api-key", "YOUR_API_KEY");
var json = await client.GetStringAsync("https://api.apiverve.com/v1/passwordbreach");
Console.WriteLine(json);Resources
Call it from Go — POST /v1/passwordbreach
No SDK to install — this is a plain HTTPS call to /v1/passwordbreach with your key in the x-api-key header. Swap in a real key and it runs as-is.
req, _ := http.NewRequest("GET", "https://api.apiverve.com/v1/passwordbreach", nil)
req.Header.Set("x-api-key", "YOUR_API_KEY")
res, _ := http.DefaultClient.Do(req)
defer res.Body.Close()
body, _ := io.ReadAll(res.Body)
fmt.Println(string(body))Resources
Call it from PHP — POST /v1/passwordbreach
No SDK to install — this is a plain HTTPS call to /v1/passwordbreach with your key in the x-api-key header. Swap in a real key and it runs as-is.
$ch = curl_init("https://api.apiverve.com/v1/passwordbreach");
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
curl_setopt($ch, CURLOPT_HTTPHEADER, ["x-api-key: YOUR_API_KEY"]);
$response = curl_exec($ch);
echo $response;Resources
Call it from Ruby — POST /v1/passwordbreach
No SDK to install — this is a plain HTTPS call to /v1/passwordbreach with your key in the x-api-key header. Swap in a real key and it runs as-is.
require "net/http"
uri = URI("https://api.apiverve.com/v1/passwordbreach")
req = Net::HTTP::Get.new(uri)
req["x-api-key"] = "YOUR_API_KEY"
res = Net::HTTP.start(uri.hostname, uri.port, use_ssl: true) { |h| h.request(req) }
puts res.bodyResources
Zero-code embed — one snippet, no backend
Drop an interactive Password Breach Checker form onto any page. The widget calls the API for you, so no key ever appears in your markup and there is nothing to deploy.
Changelog — Password Breach Checker API
Every change to this endpoint, newest first. Breaking changes ship as a new version and the previous one keeps serving — response fields are added, never removed or retyped in place, so an integration written against v1 keeps working.
Entries are picked up from dated catalog snapshots, so the first one appears after the next snapshot that moves something. A period where nothing changed produces no entry — silence is a valid changelog for the Password Breach Checker API.
Security
- CSR Parser
- DANE Record Validator
- Hash Generator
- HMAC Generator
- Password Breach Checker