Skip to main content
Live Data Broker Search scans Russian Market in real time. Russian Market is an automated marketplace where data brokers sell stealer logs — the full capture that info-stealer malware carries off an infected machine. You submit a domain, the engine queries the marketplace live, and it returns the listings that reference that domain. What comes back is the marketplace listing, not the log itself: the date, the stealer family, the victim’s country and OS, the ISP, and the file size — enough to judge the risk. The credentials and files inside stay redacted until the log is acquired. When a listing matters, you request acquisition from the same flow and an analyst buys it on your behalf.
This is different from two similarly named searches. Data Brokers (individual-source search) reads a pre-built index of broker listings gathered from forums and marketplaces that tolerate crawling. Russian Market doesn’t — it actively blocks automated access — so it can’t be indexed ahead of time and is queried live, on demand, instead. And Stealer logs reads captures already ingested into the credential corpus — here you’re looking at logs still on the marketplace shelf.
These endpoints are tagged Live Search in the reference. They don’t consume search credits; they’re governed by per-organization rate limits and a queue. All paths are relative to the base URL https://client-api.leak.center/api. Send your token on every request:

​
How it works

Unlike the broker sources behind the indexed Data Brokers search, Russian Market can’t be crawled in bulk — it actively blocks automated access. So there’s no pre-built index to read: each search queries the marketplace live, on demand, through a small managed pool of source accounts. That pool is the scarce resource, which is why searches are queued and capacity is capped. Your organization gets a slice of the pool’s capacity, metered per hour, day, and month. When you submit, your search joins the queue, an account picks it up, reads the live listings, and writes back structured rows. Two things gate a search before it runs:
  • Capacity. Each organization has a rate limit and a concurrency cap. When you’re out of headroom — or the engine trips its circuit breaker under load — new submissions are paused until capacity frees up.
  • Platform availability. Dark-web marketplaces are seized, migrate to new domains, rotate infrastructure, and deploy anti-bot defenses. When Russian Market isn’t reliably reachable, the engine reports it as unavailable and the dashboard blocks new searches until it recovers.
A failed or empty search does not mean no data exists. If the marketplace is mid-migration or shielding against scrapers, a search can fail or return partial results. Retry later, or check capacity and platform availability before assuming the log isn’t there.

​
Check capacity before you submit

live_search_capacity tells you what headroom you have right now:
When circuit_breaker_active is true, the engine is shedding load — back off rather than retrying immediately. To check the marketplace itself, live_search_platform_health reports a single platform’s availability. The primary field is is_available; the rest (circuit_breaker_tripped, available_accounts, last_success_at, reason, and so on) are diagnostics. Take the platform_id from any search’s detail or results response. live_search_create submits a query; the engine selects the platform server-side. It responds 202 Accepted — the search is queued, not finished.
The request body is one field: Search by a main domain — the engine matches listings whose data references that domain, including subdomains. The 202 response carries the search id and queue context:
Hold on to id — it drives every other call.

​
Track progress

Watch the search two ways. Poll, or stream. Poll live_search_detail until status is terminal:
status moves through pending → queued → running → completed, or lands on failed. Stop polling once it reaches completed or failed, and read error_message when it failed. The response also carries queue_position, estimated_wait_seconds, search_duration_seconds, results_count, completed_at, cached_until, and retry_count, plus the platform_id, query, priority, and created_at echoed from the search itself. Stream live_search_stream to get progress pushed as Server-Sent Events instead of polling:
The stream disables proxy buffering and closes when the search finishes or after the idle timeout (900 seconds) with no activity. Streaming is a convenience over polling, not a different result format — read the listings from the results endpoint once the search completes.

​
Read the listings

live_search_results returns the structured listings for a completed search.
The response is a page wrapper — items, total, limit, offset — plus context: search_id, query, applied_filters, and a Bitcoin reference rate (btc_usd_rate, btc_rate_updated_at) so you can convert listing prices. Default page size is 50, max 200. Each item is one marketplace listing: The fields in row_data are what the listing exposes for free — enough to gauge exposure. The credentials and files behind the log stay redacted until it’s acquired.

​
Filter the listings

Narrow the results with query parameters on the results call: stealer, os, vendor, country, isp, min_size_mb, and max_size_mb. To see which values a given search actually returned — so you can build filter controls without guessing — call live_search_results_filters. It returns the distinct stealers, os_values, vendors, countries, isps, and the size_range present in that search’s results.

​
Sweep every search at once

live_search_org_results returns listing rows aggregated across every search in your organization — useful for reviewing all live findings in one pass. It takes the same result filters, plus query (substring match on the original search query), min_date, and max_date. To list the searches themselves, live_search_list returns your organization’s search history as a page. Filter with status and page with limit (default 20, max 100) and offset.

​
Request acquisition

When a listing is worth acquiring, record the request against it and an analyst takes it from there — buys the log on your behalf and sends a formal invoice by email. Create a request with live_search_purchases_create. It takes the id of a listing as result_id, plus contact details, and responds 201 Created.
The response captures the request and its handling state: id, result_id, status, a result_snapshot of the listing, pricing (price_original, price_quoted, price_final), listing_url, analyst fields (analyst_notes, responded_at), and timestamps. A request moves through pending, then purchased, rejected, or expired. List requests with live_search_purchases_list. It returns a page (items, total, limit, offset) and accepts status, a comma-separated result_ids filter, limit (default 20, max 100), and offset.
A request is an intent-and-fulfilment record, not an automated transaction. Creating one queues a follow-up for an analyst; track its progress through the status field. Submitting a second request for a listing you already have pending returns a conflict rather than a duplicate.
  • Live search — the overview, plus Tor & I2P and Email References.
  • Stealer logs — search stealer captures already ingested into the credential corpus.
  • Data Brokers — the indexed individual-source search across broker forums and marketplaces that permit crawling.
  • API reference — every Live Search endpoint and field.