Prospecting

Fill a campaign with people from Emailchaser's contact database who match an Ideal Customer Profile. Revealing them spends credits.

Fill a campaign with prospects from the contact database

post https://api.emailchaser.com/r/prospects/source

Queues a background job that searches Emailchaser's internal contact database with the targeting criteria of an Ideal Customer Profile, reveals matching people and adds them to the campaign as leads. The profile defaults to the workspace's primary ICP when icpId is omitted. Sourcing is asynchronous: poll GET /leads?campaignId= to watch the prospects arrive. Each stored prospect costs the reveal price in credits (1 at the time of writing), reported per request as creditsPerProspect with the batch ceiling as estimatedCredits; duplicates, blocklisted domains and contacts without an email address are filtered out before any credit is spent. Repeated calls for the same campaign and profile resume the same search at its provider cursor, so they page deeper into the audience instead of re-revealing (and re-paying for) the same people.

  • campaignId integer required

    CampaignID is the campaign the sourced prospects are added to.

    Example: 123
  • count integer

    Count is how many prospects to add in this request. Defaults to 50, capped at 500. A stored prospect costs the reveal price in credits (1 at the time of writing); the response states the price it charged and the total the batch is expected to cost, so nothing has to trust this comment to stay current.

    Example: 50
  • icpId integer

    IcpID names the Ideal Customer Profile whose targeting criteria drive the search. Omitted, the workspace's primary profile is used.

    Example: 7
Fields in the 202 response
  • campaignId integer
    Example: 123
  • creditsPerProspect integer

    CreditsPerProspect is what one stored prospect debits, read from the pricing table at request time. It is reported because the price has changed twice (1 to 5 in August 2026, back to 1 in September 2026 when the contact data moved to a flat monthly plan) and every caller that budgets from a hardcoded number budgets wrong the day it changes again.

    Example: 1
  • estimatedCredits integer

    EstimatedCredits is Requested x CreditsPerProspect: the ceiling this batch can cost. The run settles against prospects actually stored, so the real debit is this or less.

    Example: 50
  • icpId integer

    IcpID is the profile that was used, echoed back so callers relying on the primary-profile default can see which one it resolved to.

    Example: 7
  • prospectSearchId integer

    ProspectSearchID identifies the search being advanced. Repeated requests for the same campaign and profile return the same id: the search resumes from its provider cursor instead of re-revealing the same people.

    Example: 42
  • requested integer
    Example: 50
  • status string
    Example: queued

Request

curl -X POST "https://api.emailchaser.com/r/prospects/source" \
  -H "Authorization: Bearer $EMAILCHASER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
  "campaignId": 123,
  "count": 50,
  "icpId": 7
}'

Response

{
  "campaignId": 123,
  "creditsPerProspect": 1,
  "estimatedCredits": 50,
  "icpId": 7,
  "prospectSearchId": 42,
  "requested": 50,
  "status": "queued"
}

Generated from the Emailchaser API's own OpenAPI definition, so it always matches the running API.