> ## Documentation Index
> Fetch the complete documentation index at: https://wiki.darknetsearch.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Live Data Broker Search

> Scan Russian Market in real time for stealer-log listings that name your domain — see what's for sale, filter it, and request acquisition.

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.

<Info>
  This is different from two similarly named searches. [**Data Brokers**](/api/guides/expert-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**](/api/guides/credentials-stealer-logs) reads captures already ingested into the credential corpus — here you're looking at logs still on the marketplace shelf.
</Info>

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:

```
Authorization: Bearer YOUR_ACCESS_TOKEN
```

### How it works

Unlike the broker sources behind the indexed [Data Brokers](/api/guides/expert-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.

<Warning>
  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.
</Warning>

### Check capacity before you submit

[`live_search_capacity`](https://client-api.leak.center/scalar-docs/#tag/live-search/GET/service/live_search_capacity/) tells you what headroom you have right now:

```bash theme={"dark"}
curl 'https://client-api.leak.center/api/service/live_search_capacity/' \
  -H 'Authorization: Bearer YOUR_ACCESS_TOKEN'
```

| Field                                         | Meaning                                          |
| --------------------------------------------- | ------------------------------------------------ |
| `searches_remaining_hour` / `_day` / `_month` | Searches left in each window.                    |
| `current_queue_depth`                         | How many searches are queued ahead of you.       |
| `estimated_wait_seconds`                      | Estimated wait before a new search starts.       |
| `accounts_available`                          | Source accounts free to run a search now.        |
| `next_account_available_at`                   | When the next account frees up.                  |
| `circuit_breaker_active`                      | `true` when submissions are temporarily blocked. |
| `circuit_breaker_clears_at`                   | When the breaker clears.                         |

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`](https://client-api.leak.center/scalar-docs/#tag/live-search/GET/service/live_search_platform_health/\{platform_id}/) 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.

### Create the search

[`live_search_create`](https://client-api.leak.center/scalar-docs/#tag/live-search/POST/service/live_search_create/) submits a query; the engine selects the platform server-side. It responds `202 Accepted` — the search is queued, not finished.

```bash theme={"dark"}
curl -X POST 'https://client-api.leak.center/api/service/live_search_create/' \
  -H 'Authorization: Bearer YOUR_ACCESS_TOKEN' \
  -H 'Content-Type: application/json' \
  -d '{
    "query": "acme.com"
  }'
```

The request body is one field:

| Field   | Type   | Required | Notes                                 |
| ------- | ------ | -------- | ------------------------------------- |
| `query` | string | yes      | The domain to match against listings. |

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:

```json theme={"dark"}
{
  "id": "a1b2c3d4-0000-0000-0000-000000000000",
  "status": "queued",
  "queue_position": 2,
  "estimated_start_at": "2026-06-22T10:15:00Z",
  "estimated_wait_seconds": 45,
  "estimated_wait": "about a minute",
  "message": null
}
```

Hold on to `id` — it drives every other call.

### Track progress

Watch the search two ways. Poll, or stream.

**Poll** [`live_search_detail`](https://client-api.leak.center/scalar-docs/#tag/live-search/GET/service/live_search_detail/\{search_id}/) until `status` is terminal:

```bash theme={"dark"}
curl 'https://client-api.leak.center/api/service/live_search_detail/a1b2c3d4-0000-0000-0000-000000000000/' \
  -H 'Authorization: Bearer YOUR_ACCESS_TOKEN'
```

`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`](https://client-api.leak.center/scalar-docs/#tag/live-search/GET/service/live_search_stream/\{search_id}/) to get progress pushed as **Server-Sent Events** instead of polling:

```bash theme={"dark"}
curl -N 'https://client-api.leak.center/api/service/live_search_stream/a1b2c3d4-0000-0000-0000-000000000000/' \
  -H 'Authorization: Bearer YOUR_ACCESS_TOKEN' \
  -H 'Accept: text/event-stream'
```

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`](https://client-api.leak.center/scalar-docs/#tag/live-search/GET/service/live_search_results/\{search_id}/) returns the structured listings for a completed search.

```bash theme={"dark"}
curl 'https://client-api.leak.center/api/service/live_search_results/a1b2c3d4-0000-0000-0000-000000000000/?limit=50&offset=0' \
  -H 'Authorization: Bearer YOUR_ACCESS_TOKEN'
```

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:

| Field                         | What it holds                                                                                                       |
| ----------------------------- | ------------------------------------------------------------------------------------------------------------------- |
| `id`, `content_hash`          | Listing identifiers. Use `id` to request acquisition.                                                               |
| `row_data`                    | The listing's marketplace fields — `Date`, `Stealer`, `OS`, `Vendor`, `Country`, `State`, `ISP`, `Size`, and links. |
| `listing_url`, `listing_date` | Where the listing lives on the marketplace, and when it was posted.                                                 |
| `price_final`, `price_btc`    | The asking price, in USD and BTC.                                                                                   |
| `scraped_at`                  | When the engine read the 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`](https://client-api.leak.center/scalar-docs/#tag/live-search/GET/service/live_search_results_filters/\{search_id}/). 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`](https://client-api.leak.center/scalar-docs/#tag/live-search/GET/service/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`](https://client-api.leak.center/scalar-docs/#tag/live-search/GET/service/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`](https://client-api.leak.center/scalar-docs/#tag/live-search/POST/service/live_search_purchases_create/). It takes the `id` of a listing as `result_id`, plus contact details, and responds `201 Created`.

```bash theme={"dark"}
curl -X POST 'https://client-api.leak.center/api/service/live_search_purchases_create/' \
  -H 'Authorization: Bearer YOUR_ACCESS_TOKEN' \
  -H 'Content-Type: application/json' \
  -d '{
    "result_id": "f0f0f0f0-0000-0000-0000-000000000000",
    "customer_email": "analyst@acme.com",
    "customer_company": "Acme",
    "customer_name": "A. Analyst"
  }'
```

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`](https://client-api.leak.center/scalar-docs/#tag/live-search/GET/service/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`.

<Info>
  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.
</Info>

### Related

* [Live search](/api/guides/live-search) — the overview, plus Tor & I2P and Email References.
* [Stealer logs](/api/guides/credentials-stealer-logs) — search stealer captures already ingested into the credential corpus.
* [Data Brokers](/api/guides/expert-data-brokers) — the indexed individual-source search across broker forums and marketplaces that permit crawling.
* [API reference](https://client-api.leak.center/scalar-docs/#tag/live-search) — every Live Search endpoint and field.