Skip to main content
This page gives you a practical map of which endpoint families exist, what they’re used for, and how they fit together in a real integration. Most customer integrations follow this pattern:
1

Define scope

Use watchlists to define scope (domains, keywords, BINs, executives, assets).
2

Query intelligence

Query Dataleaks, Exposure, and Ransomware datasets with scoped inputs.
3

Ingest incrementally

Ingest incrementally using pagination and date windows where supported.
4

Normalize and correlate

Normalize and correlate results into downstream systems such as SIEM, SOAR, a data lake, or case management.

​
Response envelope

Successful responses use a consistent top-level envelope:
Single resource
List endpoints
Batch delete

​
Health

Use this for basic connectivity checks (no auth required):
Health request

​
Watchlists

Watchlists are the foundation of authorization scope.
  • GET /api/v1/watchlists
  • POST /api/v1/watchlists/create
  • PUT /api/v1/watchlists/{id}
  • POST /api/v1/watchlists/delete
  • GET /api/v1/watchlists/stats
Many list endpoints accept an optional watchlistid query parameter, and batch-delete endpoints use a JSON request body with an ids array.
POST /api/v1/watchlists/domain, POST /api/v1/watchlists/keyword, and POST /api/v1/watchlists/bin can return:
  • 403 Forbidden when enterprise billing access is denied.
  • 409 Conflict when the corresponding workspace quota is reached (quota_domains_reached, quota_keywords_reached, quota_bins_reached).

​
Modules

  • GET /api/v1/dataleaks/credentials // requires domain
  • GET /api/v1/dataleaks/credentials/email // requires email
  • GET /api/v1/dataleaks/documents // requires domain
  • GET /api/v1/dataleaks/paymentcards/bins // requires bin
  • GET /api/v1/dataleaks/stats // requires domain
  • GET /api/v1/dataleaks/user // requires id