Pipes

Pipes are processing blocks for data enrichment. Each of your input objects will be processed by every pipe of your pipeline.

Example: The pipe PeopleGetCompanyWebsiteUrl:Email@1 processes every input object of a request. The pipe requires the input field email and produces an output field called companyWebsiteUrl.

If the pipe cannot find its required inputs in the record, it will produce a field error.

cosnt obj = {
  name: "Will Smith",
  email: "will@hollywood.com"
  // companyWebsiteUrl: "https://hollywood.com" < will be added
}

Inputs and outputs

Each pipe takes one or more input fields and produces one or more output fields. Pipe input and output fields can be cound in the 📓 pipe catalog.

To match the input requirements of a pipe you can provide the input fields via your input objects or add a pipe to your pipeline that outputs the input field.

Desining pipelines in a way that all inputs and outputs line up is probably the hardest part of working with pipe0 (it’s not that hard!).

Pipe 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.

Field Aliases

Input and output fields have default names. You can reassign fields to different names by passing a config object.

{
  "pipeId": "PeopleGetCompanyWebsiteUrl:Email@1",
  "config": {
    "inputFields": {
      "email": {
        "alias": "special-email-name"
      }
    },
    "outputFields": {
      "companyWebsiteUrl": {
        "alias": "spcial-website-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.

Flex pipes follow a specific format to declare input and output fields. Here is an example:

{
  "prompt": "Based on the name of the person {{ input name type=\"string\" required=\"true\" }} assign a character from the TV show \"The Simpsons\" to that person. {{ output value description=\"Name of a character from the TV show 'The Simpsons\'\" }}",
}

Within the text prompt you can specify any number of input or output fields.

type: “string” | “number” | “boolean”
required: “true” | “false”
description: string

Pipe Names

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.

Request Pipes

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