CampaignStack with Clay: the table feeds the workflow, the workflow feeds the table

Clay builds and qualifies the row; CampaignStack runs the conversation. Three wires connect them, all from the Clay card on your workspace's Integrations page: a Clay table posts qualified rows into a workflow through an HTTP API column, a step in any workflow pushes worked leads into a Clay table's webhook source, and an enrichment step can run one of your Clay routines on a lead before the email sequence.

Jump to the setup See CampaignStack pricing

What Clay owns

The data. Over 150 providers behind one column, waterfalls that fall through to the next provider, Claygent answering the question no database stores, and a table your ops team already lives in. Nothing on this page replaces a column. The row leaves Clay when it is ready and comes back when something happened to it.

What CampaignStack owns

Delivery on accounts that have to survive it, and the memory around it: per-account LinkedIn sessions with budgets, AI drafts that pass a critic and a review queue, the reply that reroutes the lead, the booked meeting that cancels the rest. Clay does not compete for this job, and its sequencer sends email only.

Side by side

Where each wire attaches

Three connections, what fires them, and what arrives on the other side.

	On the Clay side	On the CampaignStack side
Rows in	An HTTP API column on the table, posting the row's fields to the Clay endpoint with the workspace's Clay token in a header. Runs per row, when you choose.	The Clay integration receives the row, creates or merges the lead workspace-scoped, and hands it to the workflow the integration is attached to.
Leads out	A table with a Webhook source. Its URL is what you register on the Clay card.	An Add to list step with provider Clay, or a plain Webhook step, on any exit of the graph. Leads with an email or a LinkedIn URL qualify; a dedupe key rides along.
Enrichment	A routine you built in Clay, identified by its id (Clay's API cannot list them).	The contact-enrichment step tries providers in order; with Clay in the cascade and the routine id set, it runs your routine and writes the result onto the lead.

Setup

Set it up

Everything starts on the Integrations page of the workspace, Clay card, Set up Clay. If the card is not there yet, the Clay connector is in early access for your workspace; ask us and we will switch it on.

Link the workspace to Clay

Set up Clay asks for a Clay API key (Clay, Settings, API keys) and verifies it on the spot. Saving it shows the workspace's Clay token for inbound calls, with a Copy button, and a Clay tables section where you register the tables CampaignStack may push into.

Rows in: an HTTP API column on the table

In Clay, add an HTTP API enrichment to the table. Method POST, the URL below, header x-clay-webhook-auth with the token from step 1, and a JSON body mapping the row's columns to the lead fields. Run it on the rows you want worked; each call creates or merges the lead and enters it into the attached workflow.

https://actions.campaignstack.io/api/webhooks/clay

x-clay-webhook-auth: <token from the Clay card>

{
  "leads": [
    {
      "linkedinUrl": "{{LinkedIn URL}}",
      "fullName": "{{Full Name}}",
      "email": "{{Work Email}}",
      "title": "{{Job Title}}",
      "companyName": "{{Company}}"
    }
  ]
}

Leads out: register a table's webhook source

In Clay, create or open the table that should receive worked leads and add a Webhook source; copy its URL. On the Clay card, add the table with a label and that URL. In the workflow, add an Add to list step with provider Clay and pick the table, on the exit you want: replied, meeting booked, finished. A plain Webhook step with the body template below does the same for a table you would rather not register.

{
  "name": "{{lead:fullName}}",
  "title": "{{lead:title}}",
  "company": "{{lead:company}}",
  "linkedin": "{{lead:linkedinUrl}}",
  "email": "{{lead:email}}"
}

Optional: run a Clay routine as the enrichment step

Open the contact-enrichment step in the workflow, add Clay to the providers and paste the routine id from your Clay workspace. Providers run in order and the first match wins, so put Clay first if the routine should run before the built-in finder.

01 · Why the row leaves

A row is not a conversation

The table is the right place to decide who; it is the wrong place to run what happens next, because a conversation has state a cell cannot hold: the account it went out from, what that account has already sent today, whether the person replied and what they said. CampaignStack holds that state, and the two webhooks are the seam. The row leaves when it is qualified and comes back with an outcome, and the table stays what it is good at.

02 · Provenance

Clay leads are yours, not the shared database's

Leads that arrive from Clay are user-supplied data, so they land workspace-scoped: they never enter the shared lead database other workspaces read from and never cross a workspace boundary. They are scored against your ICPs, worked like any other lead, and your exclusions are checked at every send.

Frequently asked questions

Is the Clay token the same as my Clay API key?

No. The Clay API key is Clay's, used by CampaignStack to call Clay. The token on the card is CampaignStack's, used by Clay's HTTP API column to call CampaignStack. Rotate either from the card.

Why register tables instead of pasting a webhook URL in the step?

So the step can offer the table by name and so the URL lives in one place. A plain Webhook step still works for a one-off table; registration is the tidy version.

Does the Clay routine step cost CampaignStack credits?

No. A routine runs on your Clay credits. The built-in contact finder is the provider that charges CampaignStack credits, and only when it finds something.