Skip to main content
Live Data Broker Search queries Russian Market in real time. Russian Market is an automated marketplace where data brokers sell stealer logs: the full capture that info-stealer malware takes from an infected machine. You submit a domain or a brand keyword. The engine searches the marketplace live and returns the listings whose logs reference it. What comes back is the marketplace listing, not the log. Each listing shows the date, the stealer family, the victim’s country, OS and ISP, the file size and the price. That is enough to judge the exposure. The credentials and files inside stay hidden until the log is acquired. When a listing matters, you request acquisition through the same API and an analyst buys it on your behalf.
Two other searches have similar names. Data Brokers searches an index of listings collected ahead of time by crawling broker sites on a schedule. Russian Market answers only one search at a time and cannot be crawled in bulk, so it is searched live here instead. Stealer logs searches captures already in the credential corpus. This page covers logs still on sale.

​
Availability and cost

Availability: Live Data Broker. Cost: 1 session from your monthly Live Data Broker allowance for each search that live_search_create accepts with 202. If the call returns any other status, the session is refunded. A search that is accepted and later ends failed keeps its session. Every other call on this page uses no sessions. Each successful call also counts toward your API Calls allowance. Without the Live Data Broker feature, or when your license is not active, every endpoint on this page except the two purchase endpoints returns 403:
The two purchase endpoints need only a license in force. When it is not active, they return 403 with {"detail": "Your license is not active."}. When the month’s sessions are spent, live_search_create returns 429 and no search is created:
limit is your monthly session allowance, including any active packs. The message uses the allowance’s internal name, Hacker Forum Live Search. Do not retry until the allowance resets. Plans and quotas explains allowances.

​
Two limits: your allowance and engine capacity

Two separate limits decide whether a new search runs. The allowance is checked first. Extra Live Data Broker packs, bought in the dashboard, raise it while they are active. When the engine refuses a search, the body names the window that is full:
detail is one of Hourly search limit exceeded, Daily search limit exceeded, Monthly search limit exceeded or Concurrent search limit exceeded. retry_after is the number of seconds, sent as a string, until that window opens again. When too many of your searches are still in progress, retry_after is 90. A refused create uses no session. A fifth value, Organization is disabled, means the engine has turned off live searches for your organization. retry_after is then "None", and waiting does not help. Contact support.

​
How it works

Russian Market cannot be crawled in bulk. Each search runs live, on demand, through a small pool of managed marketplace accounts. That pool is the scarce resource, so searches wait in one queue that all organizations share. The engine picks the marketplace for you.
  1. You create a search. It joins the queue with status pending.
  2. A marketplace account picks it up. status moves through queued to running.
  3. The engine reads the live listings, keeps those that match your query and stores them as rows.
  4. status ends at completed, failed or cancelled.
A failed or empty search does not prove that no listing exists. Marketplaces move domains, change infrastructure and block scrapers. When Russian Market is hard to reach, searches can fail or return fewer listings. Check platform health and search again later.

​
Check capacity before you submit

live_search_capacity reports the engine’s headroom for your organization. It does not report your plan allowance.
While circuit_breaker_active is true, live_search_create returns 502 and refunds the session, unless the same query completed recently and its results are reused. Wait for circuit_breaker_clears_at. live_search_platform_health reports whether the marketplace is serving searches. Read is_available. reason explains a false. The other fields are diagnostics. Take the platform_id from any search’s detail or results. live_search_create takes one field, query.
query is a domain or a brand keyword. A dot decides which. The query is lowercased, and a trailing dot is dropped. It can be up to 253 characters. Use a keyword to cover every domain a brand owns in one search. Use a domain for a narrower result. An empty query returns 400. A query that breaks these rules returns 422 with a detail list that names the rule. The call returns 202. The search is queued, not finished.
Keep the id. The progress and results calls take it. If the same query completed recently, the engine reuses those results. The new search has its own id and reads completed on the first poll. It still uses a session. The listings of a reused search cannot be acquired by their id; see Request acquisition.

​
Track progress

Follow the search by polling or by streaming. Poll live_search_detail every 3 to 5 seconds:
  • pending, queued, running, retrying, healing: still in progress. Keep polling.
  • completed: done. Read the listings.
  • failed: done, with an error. Read error_message.
  • cancelled: stopped before it finished.
While the search waits, queue_position, estimated_wait_seconds and estimated_wait are recalculated on every poll. Once it ends, results_count, search_duration_seconds and completed_at describe the run, and cached_until says how long its results are reused for the same query. The response also carries platform_id, query, created_at and retry_count. Each poll that returns 200 uses one API call. A two-minute search polled every 3 seconds uses about 40. Stream live_search_stream to receive progress as Server-Sent Events over one request:
  • Each event is a data: line holding a JSON object with a type.
  • The stream ends after an event whose type is completed or failed. If the search has already completed or failed, you get that one event.
  • A cancelled search sends no final event, and the stream keeps sending keepalives. While you stream, also poll live_search_detail every 60 seconds, and stop when status reads cancelled.
  • Lines that read : keepalive arrive every 15 seconds while nothing else happens. Ignore them.
  • The connection closes if no data arrives for 900 seconds.
The stream reports progress only. Read the listings from the results endpoint once the search completes.

​
Read the listings

live_search_results returns the listings of one search, with the most recent listing date first.
  • limit defaults to 50, max 200. offset starts at 0.
  • The response holds items, total, limit and offset, plus search_id, query and applied_filters.
  • btc_usd_rate and btc_rate_updated_at give the Bitcoin rate used for price_btc.
Each item is one marketplace listing: Links lists the domains in the log that match your query. Other domains in the same log are left out. The columns in row_data are what the marketplace shows for free. The credentials and files stay hidden until the log is acquired.

​
Filter the listings

Narrow the results with query parameters on the same call. Each filter matches one row_data column exactly. live_search_results_filters returns the values present in one search’s listings: stealers, os_values, vendors, countries, isps, and a size_range with min_mb and max_mb. Use them as filter values instead of guessing.

​
Review every search at once

live_search_org_results returns listings from all of your organization’s live searches, most recently read first. It takes the same filters as the results call, plus:
  • query: listings from searches whose query contains this text.
  • min_date, max_date: listing date range, as YYYY-MM-DD.
  • limit (default 50, max 200) and offset.
The response adds search_count, the number of searches the listings came from. live_search_list returns your organization’s live searches, newest first. Filter with status, and page with limit (default 20, max 100) and offset.

​
Request acquisition

When a listing is worth acquiring, create a purchase request. An analyst reviews it, buys the log on your behalf and sends a formal invoice by email. live_search_purchases_create returns 201.
Take result_id from live_search_org_results. It returns only listings stored for your organization, so its IDs are always accepted. live_search_results can also return IDs that are not stored: for a search that reused earlier results, and for listings a later search found again. Those IDs return 404 with {"detail": "LiveSearch result not found"}.A reused search reads completed on the first poll, with search_duration_seconds at 0. If the listing you want is missing from live_search_org_results, run the query again after that search’s cached_until. A search that runs live stores its listings for your organization.
The response holds the request’s id, status, your contact fields, a result_snapshot of the listing, listing_url, the pricing fields price_quoted and price_final, the analyst’s analyst_notes and responded_at, and created_at and updated_at. status starts at pending. An analyst sets it to purchased or rejected. A request can also end expired.
One pending request per listing and email address. A second request for the same result_id and customer_email while the first is pending returns 409 with {"detail": "A pending purchase request already exists for this result and customer"}. An unknown result_id returns 404 with {"detail": "LiveSearch result not found"}.
live_search_purchases_list returns your organization’s requests, newest first. Filter with status and with result_ids, a comma-separated list of listing IDs. Page with limit (default 20, max 100) and offset.

​
Errors

Handle API errors explains how to branch on each status.

​
Endpoints

For the overview of all three live searches, see Live search.