Skip to main content
A quick search casts the widest net: give it one term — a domain, an email, an IP — and it searches every related data source at once, returning one merged result. It’s the natural starting point — run it to see what’s out there across every source, then dig deeper into the ones that matter.
Each search takes a single search_term, matched to its type:

​
What each search covers

The term you pick decides which sources run. The platform fans the search out to every source that applies and returns the findings grouped by source. Breadth varies with the term — a domain reaches 12 sources, a credit card reaches 3. Source names below are the product names you’ll see in the response’s feature_names.
A ✓ means that search type reaches that source; rows run from broadest coverage to narrowest. (Host = host name · File = file name · Card = credit card.)

​
How it works

These searches run asynchronously: you submit a search, get back a record with an id, then poll that record until every source has reported.
1

Submit the search

POST your term to the matching endpoint. It returns a search record (201) carrying an id.
2

Poll for results

Fetch the record by its id. Its result fills in per source as each one reports back.
→ retrieve_quick_search_record_with_status_update

​
Reading the results

A search record carries:
  • feature_names — the sources searched, by their product name (Leaks, Credentials, SSL Transparency Logs, Cyber Intel, …).
  • services_slugs — the same sources by their internal slug.
  • result — a map keyed by source slug, one entry per source.
  • follow_up_token — see below.
Each result entry has a status, plus either inline data (the source answered immediately) or a task_id (still working — poll for it). Entries also carry their own scoped follow_up_token.
Each source reports its own status: An async source keeps the status reported by its own status endpoint, so it doesn’t land on ok — it starts as submitted and finishes on a source-specific terminal value such as finished, Completed, or Complete, then exposes a task_id. Read it per source, not all-or-nothing. The search fans out in parallel — some sources answer instantly, others take longer, and one failing never fails the rest. Treat submitted as “keep polling” and any non-failure value as done; don’t wait for ok on an async source. Partial results are normal.

​
Pulling a source’s full findings

What you do next depends on what a source’s result entry contains. It has data → the findings are already there. Read them directly — there’s nothing more to fetch. Most sources answer this way (Leaks, SSL Transparency Logs, Cyber Intel, Telegram, Discord, Accounts, …). It has a task_id (status submitted) → the source runs as a background job. Poll the record until that source reaches its terminal status, then re-query its result endpoint with the task_id for the full findings: The follow-up token. The response carries a follow_up_token at the top level, and each source entry carries its own scoped to that one source. It’s a JWT (valid 24 hours) that ties a follow-up call back to your original search — the source, the exact query parameters, and your organization. Send it as a Follow-Up-Token header on the call above:
The Credentials follow-up requires a filter_id: a domain quick search submits with filter_id=5, and an email quick search uses filter_id=1 plus filter_parameters usernames. See Filtered credentials for the full filter catalog. An expired or mismatched token returns 401.
Need to go narrower? This hits every source for your term. To search one specific indexed source (a forum, a channel, Telegram, Discord) on its own, search that individual data source; for real-time queries against a live source, use a live search.