Work Email Waterfall Finder Verifier BYOK Clay Ready

✉️ What can Work Email Waterfall Finder do?

Give it contacts and it finds a work email for each one by chaining several finder providers, verifies every result, and returns the real per-provider spend instead of hiding it behind a credit abstraction.

Bring your own keys. You supply your own Findymail, Prospeo, Icypeas, Reoon and BounceBan keys. We supply none, we never see your credits, and you pay your providers directly at your own rates.

📦 What you get	⚙️ Features and integrations
📧 A verified work email, or an honest null 🧾 Real per-provider attribution, units and latency 💰 Observed balance movement, read from each provider 🔢 15 flat fields, one row per contact, always	🔗 Multi-provider chain in the order you set ✅ Verification after every finder, not once at the end 🔌 Per-provider circuit breaker on credit or auth failure ⬇️ Export to JSON, CSV, Excel, HTML or XML

Bought by teams who already pay for email finders and want to know what each one actually costs them per hit.

🚫 This is not a data provider and it sells you no credits. It orchestrates the accounts you already have. With no keys supplied it still runs, reports which capabilities were unavailable, charges nothing and exits cleanly.

💡 Why use Work Email Waterfall Finder?

Clay's Work Email waterfall works, and it hides what each provider cost you behind Clay credits. That is the top recorded complaint about its pricing. This returns the per-provider detail: which entry answered, what it consumed, how long it took, and what your balance actually moved by.

If you want	Read these fields
The address	email, email_status
Which provider earned its keep	found_by, chain_position
What the row cost you	provider_units_used, providers_attempted
Whether the verification is trustworthy	verification_source, verification_degraded
Run-level spend and balance movement	run_summary on the summary row

🔒 invalid means a verifier actually looked

invalid appears only when a verification provider looked and said the address will not deliver. A verifier that failed, timed out or ran out of credit never produces invalid, because a verification failure is not evidence that an address is dead. Those rows come back unverified or unknown instead, with verification_degraded set.

email_status values: valid, catch_all, catch_all_resolved, unknown, unverified, invalid, not_found, plus a few run states.

📋 What data can Work Email Waterfall Finder extract?

15 fields per contact. One row per input contact, always, including the ones where nothing was found, plus a run summary row.

Field	What it holds
contact_id	Your own id, echoed back
input_full_name, input_company_domain, input_linkedin_url	What you supplied
email	The work email found, or null
email_status	The verification verdict
found_by	The registry entry that answered, for example findymail.search_business_profile#linkedin_url
chain_position	Which position in your order returned it
verification_source	Which verifier's answer stands
verification_degraded, verification_error	True when the primary verifier failed and the chain fell back
providers_attempted	Every entry tried, with binding, outcome, latency and units consumed
provider_units_used	Credits this row consumed from your accounts
is_summary_row, run_summary	Run totals, spend and observed balance movement

The identifier binding is part of the found_by id on purpose. findymail.search_business_profile#linkedin_url and findymail.search_name#name_domain are different attempts against the same provider and they perform differently.

⚠️ Give it a LinkedIn URL if you have one. Measured on 300 contacts, one key, one hour: a LinkedIn URL hit 13.7%, full name plus company domain hit 9.3%. 14 of the hits were unique to the LinkedIn binding and 1 to name plus domain. Same provider, same hour, only the input field changed. Hit rates are cohort dependent, and yours will differ.

🛠️ How to find and verify work emails

1. Open the Input tab and supply contacts, an array of objects with whatever identifiers you have.
2. Put your provider keys in providerKeys. Every key is validated for free before any paid call.
3. Set maxProviderUnits. It is a hard ceiling on the provider credits a run may consume from your accounts.
4. Click Start.
5. Read email and email_status, then providers_attempted for the cost breakdown.

Supply every identifier you have. The chain uses the best one each provider accepts and never wastes a call on a provider whose required field you did not supply.

🧪 Using it in Clay

contacts and providerKeys are also accepted as JSON strings, because Clay sends every input as a string. A single contact is an array of one.

🔗 The default chain

1. findymail.search_business_profile#linkedin_url
2. findymail.search_name#name_domain
3. prospeo.enrich_person#any

Then verification, after each finder that returns an address rather than once at the end, because providers do not agree on what "found" means.

Icypeas is included but off by default. In 300 independent contacts it returned zero hits that Findymail had not already found, and its result-read endpoint is limited to 30 calls per minute, which puts a floor of roughly 33 minutes under a 1,000-row batch. Add icypeas.email_search#name_domain to providerOrder if you want it; its bulk path is implemented and is much faster for large batches.

No regional presets ship. We have no regional accuracy data, and shipping presets without it would be inventing them.

💵 How much does it cost to find work emails?

Two things you pay for, and they are separate.

Your own provider credits. You bring the keys, so Findymail, Prospeo, Icypeas, Reoon and BounceBan bill you directly at your own rates. Mamba Labs never sees those credits.

This actor, pay per event.

Event	Free	Bronze	Silver	Gold
Email found	$0.0200	$0.0190	$0.0180	$0.0170
Email search submitted	$0.0030	$0.00285	$0.0027	$0.00255

There is also an Actor start event at $0.00005, charged once per run per GB of memory.

💳 Email search submitted is charged once per contact entering the waterfall, hit or miss, because a miss still costs the run its provider calls. Email found is charged once per address produced. Supply providerRates with your own per-unit costs and the summary reports dollars at your rates; leave it out and it reports units only. With your own keys we do not know your plan tier or your negotiated rate, and we will not assume one.

⌨️ Input

Everything is on the Input tab. The options worth explaining:

Field	Type	Default	What it does
contacts	array	[]	The contacts. Each may carry id, full_name, company_domain, linkedin_url.
providerKeys	object	none	Your own keys. Validated for free before any paid call.
providerOrder	array	[]	Override the default chain, by registry entry id.
verificationOrder	array	[]	Override the verifier order.
maxContacts	integer	none	Cap on contacts processed.
maxProviderUnits	integer	none	Hard ceiling on provider credits consumed. Set this.
providerRates	object	{}	Your per-unit costs, so the summary can report dollars.
concurrencyHint	integer	4	Contacts in flight at once.

{
  "contacts": [
    {
      "id": "your-own-id",
      "full_name": "Satya Nadella",
      "company_domain": "microsoft.com",
      "linkedin_url": "https://www.linkedin.com/in/satyanadella/"
    }
  ],
  "providerKeys": { "findymail": "...", "prospeo": "...", "bounceban": "..." },
  "maxProviderUnits": 500
}

📤 Output

One row per contact, exportable as JSON, CSV, Excel, HTML or XML.

{
  "contact_id": "your-own-id",
  "input_full_name": "Satya Nadella",
  "input_company_domain": "microsoft.com",
  "email": "satyan@microsoft.com",
  "email_status": "valid",
  "found_by": "findymail.search_business_profile#linkedin_url",
  "chain_position": 1,
  "verification_source": "bounceban",
  "verification_degraded": false,
  "providers_attempted": [
    {"entry": "findymail.search_business_profile#linkedin_url", "outcome": "found", "latency_ms": 812, "units": 1}
  ],
  "provider_units_used": 2,
  "is_summary_row": false
}

💡 Tips

• Always set maxProviderUnits. This actor spends your money, not ours.
• Pass linkedin_url wherever you have it. It measurably outperformed name plus domain on the same cohort in the same hour.
• Fill providerRates once and every run afterward reports real dollars instead of units.
• Read found_by across a batch to see which provider is actually earning its subscription.
• Treat catch_all as a separate decision from valid. It is a real answer, not a failure.

⚠️ Known limits

Hit rates are cohort dependent. The 13.7% and 9.3% above are from one B2B cohort measured on 300 contacts with one key in one hour. Yours will differ.

A provider that runs out of credit is disabled for the rest of the run. That is deliberate, and it means a run that starts strong can finish weaker. providers_attempted records exactly when it happened.

Icypeas is rate limited by design of its API. Its result-read endpoint allows 30 calls per minute, which puts a floor of roughly 33 minutes under a 1,000-row batch on the per-contact path.

Personal email is out of scope. This finds work emails only.

Consensus threshold defaults to 0, matching Clay's default. Worth knowing: Clay's "threshold for duplicate results" is not a consensus vote. Clay's own documentation describes it as an early-exit cost control that stops the waterfall when the same address keeps failing validation across providers. They are different features and should not be confused.

Compute is negligible for this shape because the actor waits on APIs rather than crawling, measured at well under a tenth of one percent of a typical per-result price in batch. The cost that matters is your providers'.

❓ FAQ

What happens if I supply no provider keys?

The actor still runs, pushes a summary row explaining which capabilities were unavailable, charges nothing and exits cleanly. It never treats a missing key as a crash.

Why is an address unverified rather than invalid?

Because no verifier successfully looked at it. A verification failure is not evidence that an address is dead, so it is never reported as one. Check verification_degraded and verification_error.

Can I change the provider order?

Yes. providerOrder takes registry entry ids, and verificationOrder does the same for verifiers.

Do you see my provider credits?

No. You hold the keys and your providers bill you directly. The actor reports the units it observed being consumed, read from each provider's own account endpoint before and after the run.

Does it find personal email addresses?

No. Work emails only.

🧩 Want other GTM data?

Mamba Labs builds custom actors for B2B go-to-market teams. The public versions of that work live here on the Store, so our users get the same tooling we build under contract.

🧑‍💼 GTM Hiring Signal Scraper	🧱 Tech Stack Detector
📡 B2B Buying Signals Aggregator	🔑 Job Board Keyword Scanner
🔗 Domain to LinkedIn URL Resolver	🎯 ICP Fit Scorer
📋 Job Posting Monitor	📬 Domain Deliverability Checker
🏢 Company Firmographic Enricher	🌐 Company Social Presence Mapper
🪪 Company Identity Resolver	💰 Funding and Press Signal Scanner
🔄 Company Change-Event Feed	👤 People Finder and Email Verifier
🚀 Prospect Engine	🤖 AI Tooling Detector
📮 Outbound Stack Detector	📝 Publishing Frequency Tracker
⏩ Sequencer Lead Push	🏅 Workplace Program Detector
👥 Team Page People Extractor	🧭 Company Discovery List Builder

Every actor in the suite takes a domain or a company and returns one flat row, so they stack in the same Clay table without reshaping anything.

🛠️ Need something custom built for you or your team? Tell us what you are trying to find and we will build it. Talk to Mamba Labs.

🆘 Support

Something wrong, or a provider you want added to the registry? Open an issue on the Issues tab with the run id, and we will look at it.

ℹ️ Sourcing, keys and legal. This actor calls the provider accounts you supply keys for and holds no data source of its own. Your keys are used for the run and your providers bill you directly. Work email addresses are personal data under GDPR and similar laws; you decide what happens to them next and you are responsible for that use, including establishing your own lawful basis for contacting anyone.

Built by Mamba Labs.