Skip to main content

Use case

Discover which block types you can use when building workflows. Use GET /workflows/blocks to retrieve the full list and specs schemas programmatically. This page provides a quick reference for common use cases.

API Reference

See the full request/response schema and parameters in the API Reference.

Pricing

See Credits & Pricing Guide for credit costs.

Errors

For error responses (400, 403, 404, etc.), see Handling Errors.

Get available blocks

Retrieve the list of all workflow block types supported by the API, along with their specs schemas.
Returns an array of block descriptors. Each entry includes the block’s name (used as block_name when building a workflow) and a specs_schema object describing its configurable fields.

Available blocks

The UI name is the name of the block as it appears in the Workflow Builder.

Find Email

find_email finds a work email (mode: "PROFESSIONAL") or a personal email (mode: "PERSONAL") for each row. Inputs Skipping rows that already have the email With skip_rows_with_existing_input: true, put the email you already have in one of these columns: Blank, N/A and malformed values count as missing, so the row is looked up. Skipped rows keep their position and input values, cost no credits, and get email_status (or personal_email_status in PERSONAL mode) set to PROVIDED. In PROFESSIONAL mode the matched work email is also written to email when that column is blank or holds a personal address. The run’s cost estimate still counts every row, since which rows skip is only known once the run reads them. Output columns

Verify Phone

verify_phone verifies each row’s phone number against the person’s full name using the configured input column names. All twelve output columns are included. Missing output fields start as null; skipped rows retain any existing verification values. See Handling Errors for missing-input behavior. Inputs Output columns

Monitor

monitor starts one monitor over the rows that reach it. It runs once all rows have arrived and returns no rows, so place it last in the workflow. Each workflow run starts its own monitor, which keeps checking on its own schedule after the run ends. Specs A row whose input columns already supply every watched field skips the full first check: it starts from those values and waits for the schedule, where checks begin with the lightweight probe. In a mixed table, immediate setup runs only for incomplete rows. Monitors started by this block have no webhook. Retrieve the monitor a run started with GET /monitors/for-run/{workflow_run_id}/{block_id}. See Monitor Endpoints.