Versions and deprecation

Every pipe_id and search_id ends in a version, like the @3 in people:profiles:crustdata@3. This page shows how to pick the right version and how to spot one you should not use.

Pick the newest current version

A shipped version never changes. When pipe0 improves a pipe or search in a way that changes its inputs, outputs, or filters, the change ships as a new version next to the old one:

Use the highest version that is not deprecated. Versions of the same pipe or search can differ in filter names and output fields, so a payload written for @2 does not always work on @3. Check the catalog page of the version you use.

Recognize a deprecated id

A deprecated pipe or search still runs for sheets and integrations that already use it. It can be removed without notice. Don't use one in new work, even if an old example or blog post shows it.

You can tell a deprecated id in these places:

• Catalog pages. The pipe catalog and search catalog mark deprecated versions with a banner that names the id to use instead. Deprecated versions have no code example.
• llms.txt. /llms.txt lists deprecated ids in their own section at the end, each with its replacement.
• MCP server. The MCP server's list tools leave deprecated entries out. If an agent uses a deprecated id anyway, the result carries a hint naming the replacement.

Replace a deprecated id

1. Open the catalog page of the deprecated id. The banner names the current replacement. Follow that link rather than raising the version number yourself: some replacements have a different name (people:workemail:waterfall@1 became person:workemail:waterfall@1).
2. Compare the inputs, outputs, and filters on the replacement's page, and update field names in your payload and in any code that reads the response.
3. Run the new payload in sandbox mode before you switch production traffic.

For example, the deprecated people:profiles:crustdata@2 search takes a current_job_titles filter. Its replacement, people:profiles:crustdata@3, calls the same filter current_employment_job_titles:

import { Pipe0 } from "@pipe0/client";

const pipe0 = new Pipe0({ apiKey: process.env.PIPE0_API_KEY });

const result = await pipe0.searches.search({
  search: {
    search_id: "people:profiles:crustdata@3",
    config: {
      limit: 25,
      filters: {
        current_employment_job_titles: {
          include: [
            "Software Engineer",
          ],
        },
      },
    },
  },
});
console.log(result);

import requests

response = requests.post(
    "https://api.pipe0.com/v1/search/run/sync",
    headers={"Authorization": f"Bearer {API_KEY}"},
    json={
        "search": {
            "search_id": "people:profiles:crustdata@3",
            "config": {
                "limit": 25,
                "filters": {
                    "current_employment_job_titles": {
                        "include": [
                            "Software Engineer",
                        ],
                    },
                },
            },
        },
    },
)
print(response.json())

curl -X POST "https://api.pipe0.com/v1/search/run/sync" \
  -H "Authorization: Bearer $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
  "search": {
    "search_id": "people:profiles:crustdata@3",
    "config": {
      "limit": 25,
      "filters": {
        "current_employment_job_titles": {
          "include": [
            "Software Engineer"
          ]
        }
      }
    }
  }
}'

Build with an AI agent

If you let an agent like Claude Code or Cursor write your integration, point it at this page and at the catalog pages of the ids it picks. Ask it to confirm that every pipe_id and search_id in the code is current. The MCP server only lists current ids, so an agent connected to it starts from the right versions.