Prospect Search API

Search Reply Data — 1B+ contacts and 60M+ companies — by ICP filters like job title, seniority, department, industry, and location, and turn the matches into a prospect list.

Coming soon

Still marked Coming soon in Reply's API reference as of 2026-07-05 (targeted early July 2026) — check docs.reply.io for current status.

Base URL
https://api.reply.io/v3
Official reference
docs.reply.io/api-reference/live-data/start-a-live-data-search
In Reply's reference
Called “Live Data”
OpenAPI
prospect-search.openapi.yaml
Markdown twin
prospect-search.md
Scopes
contacts:readcontacts:writeai-sdr:read

What it does

The Prospect Search API — “Live Data” in Reply’s API reference — runs searches over Reply Data, Reply.io’s built-in B2B database of 1B+ contacts and 60M+ companies (see reply.io/data). The surface has two parts. Search operations: start a Live Data search from an ICP filter set, preview it before committing, get a search by id, and list past searches. Filter-resolution operations: typeahead endpoints for job titles, seniorities, departments, industries, and locations that turn free text into the canonical values the search filters accept. A sibling group, AI SDR intent signals, adds industries and technologies typeaheads for intent-based targeting used by Jason AI. Be aware of the status: every endpoint in both groups is marked Coming soon in Reply’s API reference — targeted for early July 2026 and still not live as of 2026-07-05.

The problem it solves

This is the top of the funnel. An agent that can send sequences but cannot find prospects still depends on a human to upload a CSV — or on a separately licensed data vendor (ZoomInfo, Apollo) plus an export/import pipeline to move records between systems. With Live Data search, the agent turns an ICP definition (“VP-level sales leaders at US software companies”) directly into a concrete prospect list inside the same platform that will enrich the contacts and run the outreach. One API key, one data residence, no vendor contract, no sync job. The typeahead endpoints solve a quieter problem: agents guess filter strings badly, and a search filtered on a non-canonical industry name silently matches nothing. Resolving values first makes searches deterministic.

How an agent starts using it

Once the endpoints ship: resolve each filter dimension with the typeahead operations (job titles, seniorities, departments, industries, locations — plus technologies via the intent-signals group), preview the search to check match counts, then start the Live Data search and poll it by id until it completes. Feed the resulting prospects into the Contact Data API and from there into a sequence. Authentication is the standard Reply.io scheme — API key as a Bearer token — but note that Reply has not yet published the exact scopes for these endpoints; the neighboring contacts and AI SDR groups use contacts:read/contacts:write and ai-sdr:read, which is the pattern to expect. Until the endpoints are live, treat request and response shapes shown here as provisional and confirm against docs.reply.io.

Typical agent tasks

  • Turn an ICP definition into a Live Data search over Reply Data
  • Preview match counts before committing to a full search
  • Resolve free-text filter values with the typeahead endpoints (job titles, seniorities, departments, industries, locations)
  • Poll a running search by id and list past searches
  • Look up industry and technology intent-signal values for AI SDR targeting

Inputs

NameTypeRequiredDescription
filters LiveDataFilters yes ICP filter object — job titles, seniorities, departments, industries, locations. Resolve canonical values via the typeahead endpoints before searching.
name string no Human-readable search name (start).
searchId string no Identifier of an existing search, used to get its status and results.
query string no Free-text prefix for the typeahead endpoints (job titles, seniorities, departments, industries, locations, technologies).

Outputs

NameTypeDescription
id string Search identifier used to poll status and retrieve results.
status string Search lifecycle state (e.g. pending, running, completed).
counts object Match counts — how many contacts and companies the search matched. Exact result schemas are unpublished until the endpoints ship.

Authentication

API key as Bearer token. Send Authorization: Bearer <API_KEY> on every request. Get an API key in the Reply.io app under Settings → API Keyauthentication reference.

Rate limits

100 requests/minute and 3,000 requests/hour per user (shared across all of the user's API clients). On 429, honor the Retry-After header.

Example

Request — POST /v3/live-data/searches
curl -X POST https://api.reply.io/v3/live-data/searches \
  -H "Authorization: Bearer $REPLY_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "VP Sales - US SaaS",
    "filters": {
      "jobTitles": ["VP of Sales", "Head of Sales"],
      "seniorities": ["vp"],
      "industries": ["Computer Software"],
      "locations": ["United States"]
    }
  }'
Response — 201
{
  "id": 9102,
  "name": "VP Sales - US SaaS",
  "status": "pending",
  "createdAt": "2026-07-04T09:15:00Z"
}
Error — 403
{
  "type": "https://docs.reply.io/api-reference/authentication",
  "title": "Forbidden",
  "status": 403,
  "detail": "This API key does not have the required scope for Live Data search operations."
}

Related APIs

Modules are designed to chain — combining them is the point.

Frequently asked questions

Is this API live today?

Not yet. Every endpoint in the Live Data and AI SDR intent-signals groups is marked "Coming soon" in Reply's API reference (re-verified 2026-07-05), targeted for early July 2026. The documentation pages exist now — check docs.reply.io for current status before building.

What database does it search?

Reply Data — Reply.io's built-in B2B database of 1B+ contacts and 60M+ companies (reply.io/data). It ships with the platform, so search results land in the same system that enriches contacts and runs sequences. No separate data vendor license.

Which scopes will an API key need?

Reply has not published scopes for these endpoints yet — the index marks them all "Coming soon" without scope annotations. The adjacent contacts endpoints use contacts:read/contacts:write and the AI SDR groups use ai-sdr:read, so expect the same style. Verify on the endpoint pages once they go live.