Dark Web Monitoring API: What "Real Time" Actually Means
"How do I monitor credential dumps, breaches and account takeovers in real time?"
That question reached our pages 147 times in the three months to 20 October 2026, and not one of those people clicked through (Google ranked us around fifth for it). We think we know why: most of the pages ranking for it say "real time" and then change the subject.
So let's answer it properly.
Real time in a dark web monitoring API means a deadline you can measure, on a clock somebody has named. Between a breach happening and your product doing something about it there are four clocks, and a data vendor controls two of them.
We're XposedOrNot, and we run a public breach index: 795 breaches and 11.7 billion+ records as of 22 October 2026, counted by our live API. On top of it sits the partner API, the one xonAPI+ and xonThreatIntel+ customers call. Every number below is ours unless it carries someone else's name, and all of it was pulled this week.
What does "real time" mean in a dark web monitoring API?
Start with the engineering definition, because it's older than the marketing one. John Stankovic set it down in 1988, in IEEE Computer : a real-time system is one whose answer has to be right and has to arrive by a deadline, and a correct answer that turns up late still counts as a failure.
A deadline, in other words. "Instant" never comes into it, and a result that lands after its deadline is wrong even when the data in it is right.
For breach monitoring the deadline is soft. A late alert isn't worthless, it's worth less, and it keeps losing value by the hour (we'll show how fast the other side moves, below). The question to ask any API vendor, then, isn't "is it real time?" but "which clock, and what's the deadline on it?"
We went looking for anyone who answers that. On 22 October 2026 we read the 28 readable pages ranking in US Google for "dark web monitoring api" and four close variants. Twenty-two of them use the phrase "real time".
Three put a number next to it. None of the three shows how the number was measured.
The four clocks between a breach and your alert
| Clock | Starts | Ends | Who holds it | What we can measure |
|---|---|---|---|---|
| 1. Exposure | The breach happens | The data surfaces somewhere a collector can see it | Nobody. Attackers, the breached company, the law | Nothing directly. Only the gap to clock 3 (median 69 days, below) |
| 2. Verification | The data surfaces | The breach is verified and indexed | The data vendor | Our indexing timestamp, to the minute |
| 3. Notification | The breach lands in the index | Your endpoint has the alert | The data vendor | Under 15 minutes for onboarded domains, after a breach lands in our index |
| 4. Response | The alert arrives | The exposed account is protected | You | Whatever your pipeline logs |
There's a fifth number people mean when they say real time, and it isn't a clock at all. It's lookup latency: how fast a single check answers.
Ours was a median of 23.4 ms across 10,000 production requests on 11 and 12 October 2026. We've written up where that is measured and where it isn't.
Fast lookups are useful. But a 23 ms answer about a breach that surfaced in March doesn't make the breach fresh. Keep the two ideas apart and most vendor pages read very differently.
Why clocks one and two run long
Look at the 147 breaches we added to the catalog in the 52 weeks to 21 October 2026. For each one we know the breach date the source reported and the minute we indexed it.
| Time from breach date to indexing | Breaches | Share of 147 |
|---|---|---|
| 7 days or less | 2 | 1.4% |
| 8 to 30 days | 34 | 23.1% |
| 31 to 90 days | 43 | 29.3% |
| 91 to 365 days | 26 | 17.7% |
| More than a year | 42 | 28.6% |
The median sits at 69 days, and just two of the 147 made it inside a week.
One caveat before anyone quotes that. All 147 breach dates in the window sit on the first of a month, because sources usually report a month or a year, not a day.
These are month-level estimates, then, of when exposure became visible, and for any one breach the 69 could be 55 or 85.
Why so long? Because the breached company usually doesn't know yet.
Take IBM's 2025 Cost of a Data Breach study : 600 organisations breached between March 2024 and February 2025, and 241 days on average to find and contain the breach. Or Mandiant's M-Trends 2026 , which has the median dwell time (how long an intruder sits inside before anyone notices) at 14 days for 2025, up from 11 the year before.
And the law's clocks start late too. GDPR's Article 33 gives a company 72 hours to tell the regulator, counted from the moment it becomes aware. The SEC's Form 8-K rule gives a US public company four business days, counted from the day it decides the incident is material.
Neither clock starts at the breach.
Clock two is ours. We can't split it from clock one, though, because nobody timestamps the moment data surfaces, so the 69 days covers both. Our share of it is the verification step, and the indexing minute is where the measurable part begins.
What does this mean for the promise in your product? Only this: write it from indexing, never from the breach. A "real-time" claim that reaches back to clock one is a claim about events nobody saw, and the first customer with a six-month-old breach date on a fresh alert will ask you about it.
Clock three: what happens in the 15 minutes
Here is the part a vendor can actually promise, so here is ours in full. For a domain you've onboarded, the alert goes out under 15 minutes after the breach lands in our index. It covers nothing before that.
From the $243 tier, the xonThreatIntel+ alert is one account-level webhook (the $99 tier alerts by email). You register one HTTPS URL and it fires for every domain on your account, including domains you add next month. "New" means newly acquired by us, so an old breach we index today is a new finding today (your users don't care when the breach happened, they care that their login is in it now).
The notification carries counts and a watermark (a timestamp you hand back on your next call). It never carries an email address.
{
"event": "new_findings",
"as_of": "2026-10-21T00:26:56+00:00",
"domains": [
{"domain": "example.com", "new_breaches": ["AssuranceRetraite"], "new_records": 42}
]
}Then pull the detail you need, with the watermark as your bookmark (convert the offset to Z, or URL-encode the plus):
curl "https://plus-api.xposedornot.com/v2/partner/domain-summary?domain=example.com&details=true&since=2026-10-21T00:26:56Z" \
-H "X-API-Key: YOUR_API_KEY" -H "User-Agent: yourproduct/1.0"What matters more than the 15 minutes, in our experience, is how the pieces fit.
The since filter works on the time we acquired the breach, not the breach date. Why does that matter? Because late is common: of the 147 breaches we added in the 52 weeks to 21 October 2026, 42 were already more than a year old when we indexed them, and every one of those still reaches you.
And as_of? Our order of operations is stamp first, read second. Anything we index while your request is in flight sits past that stamp, your next call picks it up, and nothing falls in a gap (should one ever show twice, the breach name makes it a one-line de-duplication).
Every delivery is signed, too. X-XON-Signature is an HMAC over the timestamp and the raw body, with a timestamp header you should reject when it's stale.
Respond with a 2xx fast and do the work on a queue. We give each delivery 10 seconds, make up to three attempts with a short backoff, then stop.
Where should the delivery go? For a platform, into the same queue that handles your other security events. For an MSSP with fifty client domains, into a small client-to-domain map first, and we've shown how that routing works step by step.
Polling instead: the arithmetic
Not every team can take an inbound webhook. Network policy says no, or the compliance desk would rather pull. Polling the same since endpoint works fine, and the only question is cadence against budget.
Each API key gets this much on the domain-summary endpoint:
| Window | Calls per key |
|---|---|
| Per second | 25 |
| Per hour | 5,000 |
| Per day | 30,000 |
| Domains monitored | Poll every | Calls a day | Share of the daily budget |
|---|---|---|---|
| 50 | 15 minutes | 4,800 | 16% |
| 50 | 5 minutes | 14,400 | 48% |
| 50 | 1 minute | 72,000 | Over the limit |
| 200 | 15 minutes | 19,200 | 64% |
Where do you stand on that budget? Every response says, in X-RateLimit-Remaining. Past 80% of the tightest window we also add an X-Client-Warning header to a request that still went through, so pace from the headers and the 429 never comes.
What cadence, then? Fifteen minutes matches our own alert window, which means polling faster buys nothing. An empty response is the normal answer most of the day (the next section puts a number on it), so read it as a heartbeat.
For per-email checks on xonAPI+, the freshness rule is simpler: a newly indexed breach is visible to the catalog lookup at once. A result we cached for a repeat check of the same address refreshes within 24 hours at most, and the next uncached check sees it immediately.
How often does a new breach actually land?
This is the number nobody publishes, and it changes how you build the consumer.
Across those same 52 weeks (147 breaches again, and yes, the same number as the search impressions above, which is a coincidence) we added breaches on 105 different days, and the median gap between one add day and the next was 2 days.
The longest quiet stretch was 21 days, and it happened twice. Seven whole weeks had nothing new at all. One week had eleven.
Weekends aren't quiet either. 38 of the 147 adds, about one in four, landed on a Saturday or a Sunday.
For your pipeline, that pattern changes a few defaults.
Don't page an engineer on silence. A week with no findings is a week with no findings. Alert on a webhook that stopped verifying, or a poll that stopped returning 200, never on an empty domains array.
Don't pause the consumer on weekends. A Saturday breach with your users in it waits until Monday otherwise, and your "under 15 minutes" promise quietly becomes "under 60 hours".
Bursts happen too. Eleven breaches in a week, or three in the same minute (we saw 29 same-minute batches in the window), is normal. Your handler should take a list of domains per notification and never assume one.
Clock four belongs to you, and it's the one attackers race
Every minute saved in clocks two and three is wasted if clock four runs for a day.
How fast is the other side? The US Federal Trade Commission ran the experiment in 2017: it posted the login details of about 100 made-up consumers to a paste site to find out (Tracking the Use of Leaked Consumer Data , FTC Office of Technology Research and Investigation, 2017).
The first unauthorised login attempt came 1.5 hours after the first posting. After the second posting, which a Twitter bot picked up, it came in 9 minutes, and the week that followed logged 1,108 attempts.
That was a public paste. In our experience most breach data moves through quieter channels first, so this is the fast end of the range. But it's the only clock in this post that's measured in minutes from the start, and it isn't ours.
Verizon's 2025 Data Breach Investigations Report found the use of stolen credentials was still the most common way in, at 22% of breaches (n=9,891). Exploited vulnerabilities came next at 20%.
The response has to be automatic, then. When a notification names your domain, the matching accounts get a flag. The flag does something at the next sign-in: a stronger factor, a forced credential change, dead sessions.
We've written that pattern up as step-up authentication on new breach exposure, and it's cheap because it only touches the exposed few.
A human reading an email at 9 a.m. on Monday is clock four left to run, and nobody designed it that way.
What to write in your SLA instead of "real time"
If you resell monitoring, or promise it inside your product, three lines will carry more weight than the phrase ever did.
| The billboard line | The line you can keep |
|---|---|
| "Real-time breach alerts" | "New breach findings for monitored domains are delivered within 15 minutes of the breach being indexed by our data provider" |
| "We detect breaches as they happen" | "Breach dates are reported as published by the source and are often months before indexing. The clock above starts at indexing" |
| "Instant API" | "Lookup responses under 100 ms for 99% of requests, measured inside the service, excluding network" |
The middle line is the one teams skip, and it's the one that saves the support ticket. For the MSSP version of this conversation, with the contract wording for clients, see what to promise about dark web monitoring.
Where the two products fit
Monitoring other people's domains (your users', your clients') is xonThreatIntel+, from $99 a month for 10 domains. The account webhook and JSON feeds come with the $243 tier and up, and every plan includes API access.
Per-email checks at production volume are xonAPI+, from $9 a month for 50 requests a minute up to 25,000 a minute. Flat monthly, no per-user fees, 30-day money back on both.
Uptime for both is a 99.99% monthly target measured by an independent monitor, with the last 90 days on the SLA page (100% as of 21 October 2026). What we keep is on Our Data. Exposure facts about the identifiers you register, never raw records.
Want to see the clocks before you sign anything? Run your own company's domain through the free check at xposedornot.com/domain , then look up any breach it names in our public catalog . Every entry carries both dates: when the breach happened and the day we indexed it.
Quick answers
How do I monitor credential dumps, breaches and account takeovers in real time?
Onboard the domains you care about with a breach-intelligence API, register a signed webhook, and act on each notification automatically (flag the exposed accounts, step up their next sign-in). "Real time" then means one measurable thing: alerts within a stated window after a breach is indexed, which for us is under 15 minutes for onboarded domains, after a breach lands in our index, and no vendor can watch the breach itself as it happens.
Is any dark web monitoring API actually real time?
Only on the last leg: across the 147 breaches we indexed in the 52 weeks to 21 October 2026, the median gap from breach date to indexing was 69 days. Every provider has a gap of that kind, because breaches surface late. What can be real time is indexing to alert, and the test of a vendor is whether that leg gets a number and a measurement.
Webhook or polling for breach alerts?
Webhook if your network allows inbound HTTPS: one URL covers every domain, deliveries are signed, and you only do work when something lands. Poll the same endpoint with a since watermark if you need pull: at 50 domains every 15 minutes that's 4,800 calls a day against a 30,000 limit, and polling faster than the alert window gains nothing.
Why did the alert say the breach happened months ago?
Because it did. The alert is new, the breach isn't, and a good alert shows both dates: in our catalog 42 of the 147 breaches added in the 52 weeks to 21 October 2026 were more than a year old on the day we indexed them.
Where the numbers came from
- Search query: Google Search Console for plus.xposedornot.com, 24 July to 20 October 2026, query "how do i monitor credential dumps, breaches, and account takeovers in real time?" (147 impressions, average position 5.1, 0 clicks).
- Ranking-page read: 32 pages ranking in US Google for "dark web monitoring api", "dark web monitoring api real time", "real time dark web monitoring", "real-time breach monitoring" and "what does real-time credential monitoring mean", fetched 22 October 2026; 28 readable; "real time" is a phrase count.
- Catalog figures (795 breaches, 11,717,075,312 records; 147 added in the 52 weeks to 21 October 2026; breach-to-index gaps; add days and weekdays; same-minute batches): the public XposedOrNot catalog at api.xposedornot.com/v1/breaches, fields breachedDate and addedDate, pulled 22 October 2026.
- Lookup latency: Cloud Run request log for the partner API check-email route, 10,000 consecutive requests, 11 and 12 October 2026 (median 23.4 ms, 99.4% under 100 ms).
- Webhook and incremental-monitoring behaviour: xonPlus console documentation, Partner API Webhook and Checking Breaches pages, read 22 October 2026.
- Rate limits: the same documentation, domain-summary endpoint, 25 a second, 5,000 an hour, 30,000 a day per key.
- J. A. Stankovic, "Misconceptions About Real-Time Computing: A Serious Problem for Next-Generation Systems", IEEE Computer, vol. 21, no. 10, October 1988 (the paper that defines real-time computing by its deadlines; paraphrased, not quoted).
- IBM and Ponemon Institute, Cost of a Data Breach Report 2025, press release 30 July 2025: 241 days mean time to identify and contain, 600 organisations.
- Google Cloud, Mandiant M-Trends 2026: global median dwell time 14 days for 2025 investigations, up from 11.
- Regulation (EU) 2016/679 (GDPR), Article 33(1); US SEC, "SEC Adopts Rules on Cybersecurity Risk Management, Strategy, Governance, and Incident Disclosure by Public Companies", 26 July 2023, Form 8-K Item 1.05.
- US Federal Trade Commission, Office of Technology Research and Investigation, "Tracking the Use of Leaked Consumer Data" (T. Yeung and D. Salsburg), presentation slides, 2017: about 100 fake consumer records posted twice to a paste site; first unauthorised access attempt 1.5 hours and 9 minutes after the two postings; 1,108 attempts in the week after the second.
- Verizon, 2025 Data Breach Investigations Report: use of stolen credentials 22% and exploitation of vulnerabilities 20% of breaches as initial access vectors (n=9,891).
- Uptime: plus.xposedornot.com/sla, 100% over the last 90 days as of 21 October 2026, independently monitored.
- Earlier posts: Under 100ms Across 11.6B Records: How Our Breach Check Works; Multi-Tenant Dark Web Monitoring: 50 Clients, One Integration; Stop Account Takeover: Step Up Auth on New Breach Exposure; MSSP Dark Web Monitoring: 5 Promises to Make, 3 to Never Make.