Skip to main content

Overview

Breach search is the best starting point when you want account, identity, and source-dataset rows from indexed breach collections. Use it when the question is “where does this email, username, phone, domain, or identifier appear across breach sources?” Think of the breach workflow in four parts:
  • search for rows with a broad query or exact filters
  • narrow the search to known breach sources, fields, dates, or structured logic
  • use autocomplete before large searches to discover valid db names and fields
  • use AI filters when a user describes the target in natural language
Successful V2 breach searches use the standard envelope: success, message, data, and _meta.
Response Example

Filters And Pagination

The current search endpoint supports:
  • q for broad auto-detected queries
  • flat filters such as email[], phone[], country[], dbname[], and password_hash[]
  • logic=and|or
  • wildcard=true
  • cursor for pagination
  • filter and filter_id for structured filtering
Use data.next_cursor when data.meta.has_more is true. See Structured Filters for operator semantics such as gte, ends_with, wildcard, exists, age/date-of-birth behavior, and filter_id merge rules.

Natural Language Filters

For customer workflows, the AI filter flow is often easier than building JSON filters by hand.

Discovery Helpers

Use the autocomplete endpoints before large searches when you need to discover valid db names, fields, or common field values.

Structured Filters

Build nested logic, ranges, existence checks, and reusable filters

Discovery Utilities

Learn how autocomplete helps choose fields and db names before searching

Pagination

Page through large result sets without losing cursor state

API Reference

Use OpenAPI for exact paths, parameters, schemas, and playground requests