Clay

What This Integration Enables

Clay is where GTM teams compose waterfall enrichment: one row goes in, and a stack of data providers fills in emails, firmographics, and social profiles column by column. The catch is that Clay is webhook-first, so everything depends on getting clean rows to the table's webhook URL at the right moment. That delivery job is what FlowRunner does. Agents post leads, signups, and CRM contacts as JSON rows the moment they appear, shape the keys so Clay maps them to columns cleanly, and route to different tables per use case through per-call URL overrides. - Push new leads and signups into an enrichment table the minute they are captured - Sync contacts and companies from a CRM or [Google Sheets](/integrations/google-sheets) into Clay for waterfall enrichment - Pre-enrich with [Apollo.io](/integrations/apollo-io) and hand the partially filled row to Clay for the remaining columns - Route different record types to different tables without reconfiguring anything - Reach any other Clay-provided HTTP URL through the generic passthrough when a workflow needs it - Stamp every pushed row with its source system and timestamp, so the table can always answer where a record came from FlowRunner's role is the orchestration around the push: deduping before rows hit the table, sequencing enrichment sources, and gating bulk runs, because in Clay every arriving row starts a chain of paid lookups. The shape of the row matters more than it looks. Clay maps incoming JSON keys to table columns, so an agent that sends consistent, well-named keys, email, first_name, company_domain, source, every time gives the table a stable schema to enrich against. Agents that normalize upstream data before the push, lowercasing domains, splitting full names, stamping the source system, save the downstream columns from cleaning up after them. That normalization is workflow logic, and it belongs in the orchestration layer, not in a spreadsheet formula someone maintains by hand.