Who is this person, and what company are they at?
Growth teams already run an enrichment waterfall by hand. Sortance runs it as a router: one key, one profile shape whichever vendor answered, a cache, a cost ceiling, a receipt per vendor — and a coverage figure that says how much came back.
The vendors, and where each one stands
Sortance holds no enrichment data of its own. Every fact in a profile was bought from a named vendor, and the response’s sources receipt says which one, how long it took and what it cost.
| Vendor | Role in the router | Status |
|---|---|---|
| People Data Labs | Broad person and company coverage with structured fields. Asked first; preferred for company headcount. | Adapter built and tested. Sortance's production contract is not yet confirmed. |
| Apollo | B2B titles, seniority and firmographics. Asked when PDL has no match or thin coverage; preferred for title, seniority and department. | Adapter built and tested. Sortance's production contract is not yet confirmed. |
| Clearbit | Adapter exists for accounts that already hold their own Clearbit key. Not a Sortance-contracted upstream. | Only with a key your account holds. Not a Sortance upstream, and storing your own key is not exposed through the API yet. |
Push sources
Some vendors identify website visitors and push what they know to you. Those are ingested, not called, and are never part of the lookup:
- RB2B. Nothing from Sortance. RB2B posts website-visitor events to an ingest URL your account mints; Sortance keeps only identified, first seen, page count and source, keyed by a hash of the address, for 30 days. The fact appears as
enrichment.visitor— “this person was on your pricing page seven times before they signed up”.
Normalization is the actual work
Every vendor has its own words for industry, seniority and department. One says financial services, another Financial Services, a third Finance. Without mapping them into one vocabulary, “only fintech companies” cannot even be written as a rule.
- Industry: a closed list of 62 values, split finely where B2B buyers actually draw lines (fintech, banking, insurance and investment management are separate). A label no mapping recognises becomes
other, and the vendor’s own text is kept inindustry_rawfor display. - Seniority:
c_suite,vp,director,manager,senior,entry,unknown. - Department: 14 values, with
growthseparate frommarketingbecause product-led teams draw that line. - Headcount: the integer when given, otherwise the midpoint of the range, with the original range kept beside it.
The policy compiler is given the same lists, so what you type is matched against exactly what the vendors are mapped into. The full vocabulary is in the policies reference.
Coverage is the honest part
No vendor knows everyone. When a field is not known it is null — never guessed, never filled from a plausible default — and coverage reports the fraction of the fields you asked for that actually came back. A profile at coverage 0.2 says very little, and the response tells you so rather than letting you find out later. Policies can read coverage directly, and every ICP score carries its own.
When two vendors answer the same field differently, the answer you get follows a per-field precedence, and the other answer is kept in disagreement rather than thrown away.
How a lookup is routed
- Cache first. Company facts by domain and person facts by a keyed hash of the address, for 30 days. A hit costs nothing.
- Company before person. Most rules are about the company; company lookups send only the domain. A person lookup runs only when a person field is needed.
- Consumer mailboxes are skipped. A Gmail address is not a company, and a person lookup on it is the most privacy sensitive and least useful thing the lane could do.
- Waterfall, not fan-out. Vendors bill per match, so calling two on every request doubles the bill on every hit. The second vendor is asked only when the first had no match, failed, or covered less than half of what was asked. Fan-out is opt-in, for when you want
disagreementon every record. - A ceiling it will not cross. A lookup that would exceed your
max_cost_usdis skipped and the receipt says so. - Only when a rule needs it. Inside /v1/decide, a profile is bought only when evaluation reaches a rule that reads one. Most signups are settled before that.
What changes for privacy
Enrichment sends the address to a vendor and brings back personal data about the person behind it. That is a real change from verification, and the trust page states exactly where that data may live: in your response, and in a cache keyed by a hash of the address for 30 days. Not in decision records, not in logs, never sent to a model.
What is not here yet
- Published pricing. Enrichment is not part of the verification rate and its pricing has not been set. See pricing.
- Your own vendor keys. The adapters accept one, but there is no endpoint to store it.
- Choosing vendors per account. Every vendor configured on the deployment is eligible today.
- A monthly enrichment allowance and a batch endpoint.