How to Connect Clay to n8n With Webhooks (Two-Way Setup)

To connect Clay to n8n with a webhook, you wire two directions. To push from Clay, add an HTTP API enrichment column that sends a POST request to your n8n Webhook node Production URL. To send data back, set that Webhook node to respond Using Respond to Webhook node and return a JSON object, which Clay writes into the same row. To create fresh rows from n8n, POST JSON to a Clay webhook source URL with a Content-Type of application/json.

Self-hosted n8n has become the default automation layer for a lot of GTM and RevOps teams, and Clay is where the enrichment lives, so the join between them is one of the most common questions we get from operators. This guide walks the full two-way setup, the payload and auth details that trip people up, and the failure points that cost you an afternoon. At DevCommX we build owned outbound systems on exactly this kind of plumbing, and the patterns here are the same ones we use when we stand up a client's signal-to-enrichment loop. For the wider picture of how these pieces fit, see our B2B outbound automation guide.

Why GTM teams are wiring Clay to n8n right now

The short answer is that n8n grew up. Through 2025 it added more than 112,000 GitHub stars and passed 150,000 by October, the fastest climb of any open-source workflow platform that year. It crossed 230,000 active users and 3,000 plus enterprise customers, hit 40 million dollars in ARR, and raised a 180 million dollar Series C at a 2.5 billion dollar valuation. That is not a hobby tool anymore.

For RevOps the appeal is specific. Clay is brilliant at finding and enriching accounts and people, but its native actions have limits. n8n gives you the escape hatch: custom code, retries, branching logic, hundreds of app integrations, and long-running jobs that Clay was never meant to run. Self-hosting on top of that means no per-execution metering, so a high-volume enrichment loop that would get expensive inside a closed tool becomes a fixed infrastructure cost you control. That ownership model is the whole point. You are not renting someone else's campaign, you are building a system your team keeps.

The two directions of a Clay and n8n integration

Before you build anything, get the mental model right. There are three flows, and confusing them is the number one reason setups break. Clay to n8n uses an outbound enrichment column. n8n to Clay uses an inbound webhook source. The full round trip combines both so a row leaves Clay, gets processed, and lands back in the same row. The table below is the map.

Direction one: push from Clay to n8n

Step 1, build the trigger in n8n. Add a Webhook node as the trigger of a new workflow. Set the HTTP Method to POST. n8n gives you two URLs, a Test URL and a Production URL. The Test URL only listens while you have the editor open and you click Listen, which is fine for debugging but useless in production. Copy the Production URL once the workflow is active.

Step 2, add the enrichment column in Clay. In your Clay table, add a column and choose the HTTP API enrichment. Set the method to POST and paste the n8n Production URL. In the body, map the fields you want to send using Clay's slash-menu references, for example the domain, company name, or LinkedIn URL from that row. Clay sends this as JSON.

Step 3, run one row and inspect. Run the column on a single record and open the n8n execution. You should see the payload arrive with your mapped fields. This is the moment to confirm field names match what your downstream nodes expect, because Clay nests values in a way that is easy to misread. Fix the mapping now, not after you have run 5,000 rows.

Direction two: send enriched data back into Clay

There are two ways to get data back, and you pick based on whether you are updating an existing row or making new ones.

Write back to the same row. This is the round trip. In the same n8n workflow triggered by the Webhook node, open that Webhook node and set its Respond option to Using Respond to Webhook node. Do your enrichment work in the middle of the workflow, then end it with a Respond to Webhook node. Set Respond With to JSON and define the exact object you want Clay to receive, or use First Incoming Item to pass through the last node's JSON. Clay captures that response in the HTTP API column and you can then reference those returned fields in new columns on the same row. No second table, no re-import.

Create new rows from n8n. When the enrichment starts inside n8n, for example a scheduled scrape or a CRM trigger, you push into Clay instead. In Clay, click Add at the bottom of a table, search Webhooks, and choose Monitor webhook. Clay gives you a unique URL and an optional auth token. In n8n, use an HTTP Request node with method POST to that URL, send your data as a JSON body, and include the Content-Type header. Each POST becomes a row. Clay's auto dedupe can merge against a key field so you update rather than duplicate.

Authentication and payload structure

The Content-Type header is not optional. The single most common silent failure is sending a body without a Content-Type of application/json. When that header is missing, Clay may accept the request but never create the row, and you get no obvious error. Set it explicitly on every n8n HTTP Request node that targets a Clay webhook.

Auth tokens are shown once. When you create a Clay webhook source you can add an authentication token to the request header. Clay displays it a single time, so copy it immediately. If you lose it you regenerate, which invalidates the old one. On the n8n side, store it as a credential or an environment variable rather than pasting it into the node in plain text, especially on a shared self-hosted instance.

Keep payloads flat and named. Clay reads JSON best when keys are predictable and values are simple. Send a flat object with clear field names rather than deeply nested structures, and avoid sending the entire row when you only need three fields. Smaller, explicit payloads are easier to map, cheaper to run, and far easier to debug when something drifts.

Common failure points and how to fix them

Red cells on the HTTP API column. A red error indicator on the enrichment cell almost always means one of three things: the target URL is wrong, the auth header is incorrect, or the response format is not what Clay expected. Open the cell, read the raw response, and check the n8n execution log in parallel. Nine times out of ten the URL is the Test URL that stopped listening.

429 rate limit errors. Clay throttles submissions by plan, and lower tiers cap records per hour. A 429 is a scheduling signal, not a bug. It means slow down. Add a delay in the enrichment step, and in n8n use the Retry On Fail setting or a Loop Over Items and Wait pattern to chunk requests and pause between batches. Use exponential backoff with random jitter so parallel workers do not all retry in lockstep, and cap the retry window around 60 to 120 seconds for enrichment work.

Timeouts on slow providers. If your n8n workflow calls a slow third-party API, the request can exceed Clay's default timeout. Clay's HTTP API timeout defaults to 300 seconds and you can raise it by adding a timeout value in the request body for genuinely slow jobs. Better still, decouple: have n8n acknowledge fast, then push results back through a separate Clay webhook once the slow work finishes.

The silent 50,000 cap. Each Clay webhook source accepts up to 50,000 submissions, and that limit persists even after you delete rows. When a webhook quietly stops accepting data, this is usually why. Create a new webhook source on the same table, or on Enterprise use auto-delete passthrough tables for unlimited throughput.

Wrong Respond mode. If the round trip returns nothing, check that the Webhook node Respond option is set to Using Respond to Webhook node. If it is left on the default immediate response, n8n replies before your enrichment runs and Clay gets an empty payload. Only the first Respond to Webhook node in a workflow fires, so do not scatter several.

A real workflow: signal to enriched row

Here is how the pieces come together in an owned outbound system. A buying signal fires, say a target account posts a hiring role or a funding event lands. n8n catches it, hits a Clay webhook source, and a row is created. Clay runs its native enrichment, then an HTTP API column pushes the account back to a second n8n workflow that scores it against your ICP, checks your CRM for an existing owner, and drafts a first-touch angle. n8n responds with that score and angle, Clay writes it into the row, and only accounts above the bar flow into sequencing. This is the loop we build for clients, and it is the reason a system can go from setup to 40 plus qualified demos in around six weeks. It triggers on real behavior, not a static list. If Clay enrichment is the part you want to go deeper on, our Clay data enrichment fields and integrations guide maps the columns worth wiring, and if HubSpot is your system of record, the Clay to HubSpot integration guide covers the write-back side.

Test the loop before you scale it

Enrichment mistakes are expensive because they run in bulk, so validate on a handful of rows first. Run the HTTP API column on three to five records, then open each n8n execution and read the incoming payload field by field. Confirm the keys match what your downstream nodes reference, because a single renamed field breaks every row silently rather than loudly.

Watch the response, not just the request. A green cell in Clay means the request succeeded, not that the data is correct. Expand the returned JSON and check the actual values landed in the columns you expect. For the round trip, verify the Respond to Webhook node returns the object you think it does by pinning the last execution and inspecting its output before you trust it at volume.

Version your workflow. Once a loop works, avoid editing the live n8n workflow that Clay points at. Duplicate it, change the copy, and repoint Clay's URL only after you have tested the new version. On self-hosted instances, keep the webhook path stable so you do not have to update every Clay column each time you iterate. Small discipline here saves you from a table full of half-enriched rows.

Build owned outbound systems that you keep

A Clay and n8n webhook loop is a small piece of a much larger machine, but it is the piece that turns enrichment into action you own outright. DevCommX designs and builds these signal-based systems end to end, from the trigger to the enriched row to the sequenced demo, and hands you infrastructure your team runs, not a managed service you rent. If you want a loop like the one above mapped to your pipeline, talk to us about your GTM stack.

Further Reading

• n8n Docs: Respond to Webhook node
• Clay Docs: Webhooks in Clay
• n8n Docs: Handling API rate limits

FAQ

Can Clay send data to n8n and get a response back in the same row?

Yes. Use a Clay HTTP API enrichment column to POST the row to an n8n Webhook node, set that Webhook node to respond using the Respond to Webhook node, and return a JSON object. Clay writes the response fields straight back into the same row, so you get a true round trip without a second table or a manual re-import.

What is the difference between a Clay webhook and Clay's HTTP API enrichment?

A Clay webhook source is an inbound endpoint that creates new rows when something POSTs JSON to it, so it is how n8n pushes data into Clay. The HTTP API enrichment column is outbound. It fires a request from an existing row to a URL like your n8n webhook and captures the response back into that row. You often use both together.

Why is my n8n webhook not writing data back into Clay?

The two usual causes are a missing Content-Type header of application/json and a Webhook node still set to respond immediately. Set the Webhook node Respond option to Using Respond to Webhook node, add a Respond to Webhook node that returns valid JSON, and confirm you copied the Production URL, not the Test URL, which only listens while the editor is open.

Do I need to self-host n8n to connect it to Clay?

No. Both n8n Cloud and a self-hosted instance expose the same Webhook and HTTP Request nodes, so the Clay integration works identically. Teams pick self-hosted mainly for cost control at high volume, data residency, and unlimited executions. If you self-host, just make sure the instance is reachable over HTTPS on a public URL so Clay can reach it.

How do I handle Clay's 429 rate limit errors when calling n8n?

A 429 means slow down, not broken. Clay throttles submissions by plan, so space out requests, add a short delay in the enrichment step, and in n8n use Retry On Fail or a Loop Over Items and Wait pattern to chunk requests. Use exponential backoff with jitter and cap the retry window around 60 to 120 seconds for enrichment jobs.

Is there an n8n community node for Clay?

Yes. Community nodes such as n8n-nodes-clay let you create or update Clay records from n8n without hand building the HTTP Request, and they support Clay's auto dedupe on write. They are optional. The plain Webhook and HTTP Request nodes cover every pattern in this guide, and core nodes are the safer choice on locked down self-hosted instances.

👉 Connect Clay to n8n