Skip to main content
A waterfall is a maintained sequence of data actions for one bounded outcome, such as a work email or mobile number. Each step runs only when the preceding step does not meet the Play’s current result rule. Once a step succeeds, later steps do not run. Use a waterfall when the outcome matters more than the source. Use a direct tool when you specifically need one provider’s data or contract.
A work-email waterfall: pattern validation and one provider miss, the next provider returns a valid email, and all remaining providers are skipped.

A waterfall stops when its result rule is met. A miss advances to the next configured step; steps after a valid result do not make provider calls.

​
Choose a maintained waterfall

Use a maintained prebuilt Play when the input and desired result match one of these routes. Each guide shows the input contract, a safe validation command, and how to run a representative pilot.

Work email from name and domain

Resolve a work email from first_name, last_name, and domain.

Work email from LinkedIn

Resolve a work email when a LinkedIn profile URL is your strongest identifier.

Personal email

Use the maintained route for a consumer email, not a work email.

Mobile phone

Resolve and validate a mobile number from person-level input.

Contacts by role

Find contact candidates at a company when you have a domain and role intent.

All example prebuilt Plays

Compare the maintained input and output contracts before choosing a route.

​
Inspect the live route before you run it

The prebuilt reference identifies a maintained route; its current contract is the source of truth for required input, result rules, and available output. For example, inspect the name-and-domain work-email waterfall with:
plays check confirms that the prebuilt is available. It does not deploy a Play, start a run, call a provider, or spend Deepline credits. Use the corresponding prebuilt/<name> reference from the catalog below for another waterfall.

​
What stays true as the route changes

  • The Play records the result and the steps that ran.
  • A no-result is a valid outcome; Deepline does not invent one.
  • Provider availability, input quality, validation rules, and the configured route can change. Inspect the live Play instead of relying on a fixed list.
  • The Deepline-credit price depends on the steps that actually run and your workspace billing mode. Pilot representative rows and review the displayed price before a larger run.
email_validated means that the final candidate passed the current Play’s configured validation gate. It is not a general promise of delivery. For an executable work-email guide, see Email Waterfall. For the decision between a maintained lookup and workspace-owned code, see Prebuilt Plays.
A successful waterfall result is specific to its Play. Review the returned value, source, validation state, no-result reason, and per-step outcomes on a representative pilot before you run a full file.
This catalog is generated from the prebuilt registry. It contains every non-batch prebuilt play that is visible in the dashboard and callable as prebuilt/<name>. Batch counterparts, hidden support plays, and legacy tool aliases are intentionally excluded.Some older CLI examples use native tool IDs such as name_to_linkedin_url_waterfall. Those are compatibility aliases, not dashboard catalog names. Use the canonical prebuilt/<name> reference when selecting a prebuilt play directly.For new LinkedIn workflows, use the (HarvestAPI) variants in this catalog. The same-named entries without -harvestapi remain callable compatibility IDs for existing saved workflows; do not select them for new plays.