Skip to main content
POST
Match Prospects

Introduction

The Match Prospects endpoint allows users to accurately match individual prospects to unique Prospect IDs using multiple fetchers, such as email, phone number, LinkedIn profile, or name and company combination. This ensures accurate lead identification and enhances sales and marketing workflows. Key Benefits:
  • Match and validate lead data across multiple fetchers.
  • Enhance B2B prospecting by linking leads to business profiles.
  • Improve lead scoring and segmentation with high-quality matches.
  • Reduce data duplication and inconsistencies.

Endpoint: POST /v1/prospects/match

How Matching Works: The Waterfall

Matching is not a single lookup — each record you send runs through a sequential matching waterfall. Identifiers are attempted in a fixed priority order, from the most reliable to the least. As soon as a record matches at a step, it is resolved and removed from the waterfall; later steps only apply to records that are still unmatched.
business_id is supplementary context, not a required identifier. When provided, it is applied at every waterfall step to scope the match to a specific company, which improves precision. It is never used to match a prospect on its own.
What is never matched:
  • full_name on its own — full name is only matched together with company_name (step 4) or business_id (step 5). A record containing only full_name always returns prospect_id: null.
  • company_name on its own — company name is only used in combination with full_name.
  • business_id on its own — it scopes a match to a company but cannot identify a prospect by itself.
Practical implications:
  • If a record contains multiple identifiers (e.g., both linkedin and email), it is matched at the highest-priority step that succeeds — in this example, LinkedIn is attempted first, and email is only tried if the LinkedIn match fails.
  • Each record is matched at most once. Once matched, it does not continue to lower-priority steps.
  • Adding business_id never hurts — it refines every step it participates in.
  1. Input: Provide a list of prospects with at least one fetcher (e.g., email, phone number, LinkedIn URL, or name & company).
  2. Processing: Each record runs through the matching waterfall described above — identifiers are attempted in priority order (LinkedIn → email → phone → name & company → name & business ID), and a record exits the waterfall as soon as it matches.
  3. Output: A structured response with matched Prospect IDs, maintaining the same order as the input list. Records that cannot be matched return prospect_id: null.
Bash
Note the fourth record: it contains only full_name, so it never enters any waterfall step and returns prospect_id: null.
JSON
  • Provide the strongest identifier you have. LinkedIn URLs match with the highest confidence, followed by email and phone. Name-based matching is the last resort in the waterfall.
  • Use multiple fetchers whenever possible — the waterfall automatically uses the highest-priority one that succeeds.
  • Combine with business_id to refine matches to a specific company — it improves precision at every step, and it is required for matching on full_name without a company_name.
  • Never send full_name alone — it will always return null. Pair it with company_name or business_id.
  • Ensure accurate and up-to-date data for improved results.
  • Handle null values in responses where no match is found.
  • Use the input field when sending multiple queries to match your queries with the results.
For more details on request formats and usage, refer to the API documentation.
Rate limits are counted per query, not per request. Each prospect in the prospects_to_match array counts as a separate query toward your rate limit. A single request that matches 50 prospects consumes 50 queries from your 200-queries-per-minute limit — not 1. Batching reduces HTTP/network overhead, but it does not reduce the number of queries counted against your rate limit. Size your batches accordingly.

Authorizations

api_key
string
header
required

Body

application/json
prospects_to_match
ProspectMatchInput · object[]
required
Required array length: 1 - 50 elements
request_context
Request Context · object | null
Example:

null

Response

Successful Response

This is base response model for all responses in partner service.

response_context
ResponseContext · object
required
total_results
integer
required

The total_results number matched prospects

total_matches
integer
required

The total number of matches.

Required range: x >= 0
matched_prospects
(ProspectMatchOutputWithError · object | ProspectMatchOutput · object)[]

A list of matched prospects ids represented by MD5 hashes. May contain None for unmatched items.