Pipes

Pipes are processing blocks for data enrichment. Each pipe requires input fields and emits output fields to a pipeline.

Visit the 📓 pipe catalog to look for pipes. You can request a new pipe  if your use case is not covered yet.

Configuration

When creating a pipeline request you can pass additional configuration to pipes. The configuration for a pipe can be found in the pipe catalog.

It is almost always safe to assume that you can point the input and output fields of a pipe to an alias.

Input aliases

Providing an alias for an input field points the field to a different input field.

If your input objects store the email address under the key special-email-name, you would need to point the pipe to this field in order for it to work.

{
  "name": "PeopleBusinessEmailWaterfallV1",
  "config": {
    "inputFields": {
      "email": {
        "alias": "special-email-name"
      }
    }
  }
}

Output aliases

Providing an alias for an output field is useful to avoid conflicts. Every pipe will emit new fields to your pipeline. If you want to add pipes to your pipeline that emit the field email, you have to change the name of at least one of these output fields for your pipeline to be valid.

Additionally, this is useful if you add the same pipe more than once to your pipeline.

{
  "name": "PeopleBusinessEmailWaterfallV1",
  "config": {
    "outputFields": {
      "phoneNumber": {
        "alias": "special-phone-number-field-name"
      }
    }
  }
}

Flex pipes

As stated earlier, it is almost always safe to assume that you can point the input and output fields of pipes to aliases. The only pipes where this is not possible are pipes that run generic AI prompts. These pipes receive their input fields from a prompt and have user-defined flexible output fields.

Since the user of the pipe is already in control of the field names, there is no need to assign aliases.

Naming conventions

Pipes are named in a consistent way so you can understand what a pipe does by reading its name.

Every pipe name follows the following format:

{Category}{Action}{Source}[:{InputType}]@{Version}

Here’s what each part means:

1. Category: Defines the target of a pipe. This mostly defines if you can get company or people data from the pipe.

2. Action[Target]: Describes what the pipe does. This is usually a combination of an action (verb) and target (ex. GetEmail, ValidatePhoneNumber).

3. Source: Defines who supplies the data to run this pipe. If the data is provided by a single provider it’s usually their name (ex. ZeroBounce ). If the pipe combines multiple providers this section refers to a broader method like Waterfall.

4. InputType (optional): To avoid naming collisions for pipes with the same action and source but incompatible input groups we sometimes add a section to specify the main input for this pipe.

5. Version: Pipes are regularly updated to fix bugs, improve quality, optimize cost, etc. If we introduce a breaking change this version number will be increased so you can update at your own pace.

Naming category

When looking for a specific pipe you may ask yourself if a pipe will be found in the ‘people’ or ‘company’ category. While this is clear for most pipes, it is a little trickier for others. Let’s take the pipe PeopleGetCompanyWebsitePipe0@1. The pipe uses the email address of a person to generate the website URL of a company.

In cases like these, you can assume that the input of the pipe conveys intent. The pipe inputs (email address) are people data. We assume users are using the pipe to enrich people data since a person is the subject of the action.

In short, the pipe category is determined by its inputs.