Audience: developers. The public API requires a Pro plan or above (self-serve) or an AppSumo Tier 5+ license. Support agent: confirm the user's plan grants API access before giving API advice.
TL;DR: Three enrichment types. partial = a verified business email plus the contact's profile (LinkedIn, job title, company, firmographics) for 1 credit, phone_only = phone only (10 credits), full = partial plus a phone number (11 credits). Phone is the only thing partial omits. The bulk list endpoint spells phone_only as phone-only (hyphen) under its scope field, but the pricing is identical.
Enrichment Types
Every Cleanlist enrichment is one of three types. The type controls which data points the waterfall goes looking for, and the cost.
| Type | What you get | Cost / lead |
|---|---|---|
partial | Verified business email plus profile (LinkedIn URL, job title, company, firmographics) | 1 |
phone_only | Phone number only | 10 |
full | Everything partial returns plus a phone number | 11 |
Phone discovery is more expensive than email because it draws on premium phone providers — that's why full (11) is partial (1) plus the phone cost (10).
partial is not literally email-only. The waterfall stops once it finds a verified email, but the profile data gathered along the way (LinkedIn URL, job title, company name, industry, headcount) is written to the lead too. The only field partial doesn't get you is the phone number — that's what full adds for 10 more credits.
Field names by endpoint
The same three types appear under slightly different field names depending on the endpoint:
| Endpoint | Field | Accepted values |
|---|---|---|
POST /enrichment/person | enrichment_type | partial, phone_only, full |
POST /enrichment/bulk | scope | partial, full, phone-only |
POST /lead-lists/{id}/csv-import | enrichment_type | partial, phone_only, full |
POST /enrichment/by-task | data_points | derived (see below) |
The bulk list endpoint uses phone-only (hyphen) under scope; the person and CSV endpoints use phone_only (underscore) under enrichment_type. They mean the same thing and cost the same.
By-task: data points → type
The by-task cohort endpoint takes data_points instead of a single enum, and derives the type:
data_points | Resolved type | Cost / lead |
|---|---|---|
["Email", "Phone"] | full | 11 |
["Phone"] | phone_only | 10 |
["Email"] | partial | 1 |
A cohort with no Email or Phone data point (for example LinkedIn-only) is rejected with a validation_error (400) — at both /credits/estimate and dispatch — and costs nothing. LinkedIn is already in the search result, so it has a per-data-point price of 0 and never triggers a paid waterfall.
Legacy include_phone
The single-person endpoint also accepts a legacy boolean, include_phone, kept for older callers:
include_phone: false→partial(email + profile, no phone)include_phone: true→phone_only
When set, the explicit enrichment_type field always wins. New integrations should use enrichment_type — it's the only way to express full.
Choosing a type
- Building an outbound email list? Use
partial. Cheapest, highest fill rate. - Cold calling? Use
phone_only. - Multi-channel (email + dialer)? Use
full— one call, both channels, cheaper than two separate runs.