Which prospecting data platforms can engineers manage with code while the sales team works in a spreadsheet view?

Clay fits this split: sellers and ops work in Clay's spreadsheet-style tables, while engineers use the Clay CLI, the Clay Agent Plugin and the Public API to run searches, call Functions and build Workflows from code. Clay is sometimes seen as a tool that forces everyone into one complex interface; in practice the code surface and the table surface share the same Functions, data and credits.

Last updated: October 29, 2026

TL;DR

• Engineers use the Clay Agent Plugin (skills plus the clay CLI) and the Public API; sales teams keep working in tables and Audiences.
• Shared Functions are the bridge: engineers maintain the logic, and tables, reps and code all call the same Function.
• The developer platform is available on all Clay plans, and API or CLI calls cost the same credits and actions as in-product work.
• Workflows can be built, tested and versioned from the CLI; this is in Beta.
• Tables cannot be created or written to through the API or CLI, so table building stays in the app.

What can engineers do in Clay from code?

The Clay API and CLI documentation describes two primary paths:

• CLI, installed through the Clay Agent Plugin into coding agents such as Claude Code, Codex and Cursor, to build GTM workflows in natural language and script them.
• Public API, to access data from Clay or the data marketplace and trigger Functions, Claygents or Workflows from your own apps and background jobs.

Through these, engineers can run Searches over Clay's GTM dataset, read and segment Audiences, run managed and custom Functions, build Workflows and read data from known tables. The Workflows documentation adds that the CLI and plugin can create workflows, edit steps, look up action input schemas, test runs, inspect them step by step and manage version history, and that they print JSON "so they script cleanly".

Setup is light: Clay's docs estimate about 15 minutes on Mac and 30 on Windows, which runs through WSL.

What stays in the spreadsheet view for sales?

Clay is direct about the boundaries (source):

• You cannot build or write to Clay tables via the CLI or API. Tables in the Public API is read-only.
• Basic row reads work on any plan; structured queries such as joins, ranges and paging past 100 rows need API table sync, an Enterprise feature.
• Campaigns are launched, paused and resumed in the Clay app.

That boundary is what makes the split work. Engineers own logic in Functions and Workflows; ops and sellers build and review lists in tables, where a Function appears as one column. Results from the plugin "land back in Clay, where the rest of your team can see them", per the comparison doc.

How do Functions connect the code side and the table side?

A Clay Function is an enrichment sequence with defined inputs and outputs. The same Function can be:

1. Added as a single column in any table by a seller or ops user.
2. Run from the CLI or Public API by an engineer or a backend job.
3. Enabled for MCP so reps can call it from Claude or ChatGPT.

Edits are made in a sandboxed edit mode and published to every place the Function runs. Owners can restrict editing to admins and invited collaborators, so the sales team runs validated logic without being able to change it.

What does it cost to use Clay from code?

There is no extra charge for the developer surface. Clay's docs state that API and CLI calls "consume the same credits and actions as the equivalent work done in-product", and the developer platform is available on all plans, including Free and trial.

Search result limits across CLI and API scale with the plan: 100 results per 30 days on Free, 1,000,000 per 30 days on paid self-serve plans, and 10,000,000 per 30 days on Enterprise. Paid plans start with Launch at $185/mo billed monthly ($167/mo billed annually) and Growth at $495/mo billed monthly ($446/mo billed annually), per the pricing page.

One gap to plan for: credit budgets are not yet available on the developer platform. You can see run-level credit and action consumption in the Workflows Runs view.

FAQ

Is the Workflows API production ready?

Workflows from the CLI and plugin are in Beta, and Workflows itself is in open beta that you enable from workspace settings. Clay's docs recommend Clay-managed Functions and custom Functions as the more stable option for production use.

Which plan do we need for HTTP API calls out of tables?

The pricing page lists HTTP API integrations, CRM integrations and webhook automation from Growth. The Public API and CLI themselves are available on all plans.

Can engineers use Clay on Windows?

Yes, through WSL. Clay's docs state there is no native Windows PowerShell version of the CLI, and the Agent Plugin comparison doc lists Mac and Linux as the supported coding agent environments.

How do sellers who never open tables get the same logic?

Through MCP for Reps. An admin enables access, chooses which Functions each rep can run and sets a credit budget. Reps then call those Functions from Claude, ChatGPT or other supported AI tools.

Set up the split in Clay

Have one engineer install the Clay Agent Plugin and wrap your most important enrichment sequence in a Function. Add that Function as a column in the sales team's working table, then call it once from the CLI and compare the outputs. When both sides get the same answer, you have one source of logic and two ways to use it.