Clay changed how it charges on 11 March 2026, and the change inverted the main argument for running a hybrid stack. This page is the rewrite that inversion forced.
The old logic was simple. Clay's meter ran when Clay did the work, so you moved the heavy work to n8n, Apify and your own API keys, and called back into Clay through an HTTP request that cost nothing. That last step is the part that broke. Clay now bills orchestration as well as data, every HTTP call spends an Action, and HTTP access moved up a plan tier. The escape hatch has a price and a higher entry fee.
Some of the hybrid case survives that intact, and some of it does not. This page works through which is which, what the outside tools actually cost in 2026, and how to tell whether a given piece of work belongs in Clay or outside it.
If what you want first is the pricing model itself, the plans, the two credit pools, the allowances and whether anything rolls over, that is covered in what Clay costs to run in 2026. This page assumes it and picks up at the build decision.
Clay used to charge for data and let the plumbing run free. Now it charges for both, and the plumbing is the meter people hit first.
Marketplace data got 50 to 90 percent cheaper. Multi-step tables, HTTP calls, bring-your-own-key AI columns and CRM pushes all got a price they did not have before. Any comparison you ran in 2025 between doing it in Clay and doing it outside is now wrong in both directions at once.
What the March change did to the hybrid stack
Three things moved, and they do not all point the same way.
Buying data inside Clay got cheaper. The same release that introduced Actions cut marketplace prices by 50 to 90 percent across most providers and stopped charging for lookups that return nothing. If your reason for sourcing emails outside Clay was purely the credit price per record, that reason is weaker than it was, and worth re-pricing rather than assuming.
The handoff stopped being free. Every HTTP request a Clay table makes is now an Action. The pattern this page used to recommend, calling an external service from inside a table so that Clay never touches the expensive part, now carries a per-record cost. It is a small cost per call, priced at fractions of a cent, but it is a count where there was none, and it scales with rows.
HTTP access moved up a tier. It used to sit on the $349 Explorer plan. It now sits on Growth at $495. Anyone who designed a stack around Clay as an orchestrator calling their own services had their floor raised by $146 a month for the privilege of continuing to do what they were already doing.
That last point is what practitioners reacted hardest to, and the objection is fair on its own terms. Clay users pushed back publicly on exactly this, that HTTP calls used to be free and are now a paid action, and agencies running action-heavy client workflows said the recommendation had become harder to make. Read the analysis published since March with the incentives in view, though. A large share of it comes from companies selling something adjacent to Clay, and the framing tends to follow the business model.
The step count that decides where work belongs
Here is the test we run, and it takes about five minutes per table.
Divide the Actions in a plan by the Data Credits in the same plan. Launch gives 15,000 Actions against 2,500 Data Credits, which is six Actions for every Data Credit. Growth gives 40,000 against 6,000, which is about six and a half. The plans are built on an implied ratio: roughly six platform operations for every piece of data you buy.
That ratio is our arithmetic on the published allowances rather than a number Clay states, and it is a plan-level average rather than a rule about any single table. Used as a threshold, though, it answers the build question directly. Count the operations each record passes through: every enrichment, formula, AI column, conditional and push. Under about six, the plan's shape fits what you are doing, Data Credits will be your binding constraint, and moving work outside Clay buys you complexity rather than savings. Well over six, and you are exhausting Actions at a fraction of the data volume the plan advertises, which is the case where an external workflow that returns one finished record for one Action starts to pay.
The threshold is the point. Not the tool preference, not the philosophy about what Clay is for. A twelve-step table on 1,000 records is 12,000 Actions. The same work done outside and returned once is 1,000. Whether that difference is worth building depends entirely on how often you run it.
What the work actually costs outside Clay
The three tools we reach for, with their 2026 list prices and the shape of each meter, because the shape matters more than the headline number.
| Tool | What it costs | The meter that matters |
|---|---|---|
| n8n, self-hosted | Free software, unlimited executions, plus whatever the server costs | None. This is the reason self-hosting keeps winning for high-volume branching |
| n8n Cloud | $24 a month, or $20 billed annually, for 2,500 executions on Starter | One execution per complete workflow run, not per node. A fifteen step workflow run 100 times is 100 executions |
| Apify | Free carries $5 of monthly usage. Starter is $29 a month including $29 of usage, at $0.20 per compute unit | Two layers. The plan buys platform usage; many Store Actors charge per result or per event on top of the compute their run consumed |
| Anthropic API | Claude Sonnet 5 at $2 per million input tokens and $10 output. Claude Haiku 4.5 at $1 and $5 | Tokens. A classification prompt and its answer is a few hundred tokens, so the model cost of classifying a list is cents |
n8n's execution billing is the strongest remaining argument for the hybrid pattern, and it is the one the March change did not touch. Per-run billing against per-step billing is a difference that widens with every node you add, which is exactly the regime where Clay's Action count becomes the constraint.
The AI economics are the other clear win, and they widened rather than narrowed. An AI column costs an Action per record on top of whatever the model costs, whereas calling the model yourself costs only the model. Two further levers make that gap larger: prompt caching cuts repeated context to roughly a tenth of the input price, and the Batch API is half price for work that does not need to come back immediately. Enrichment scoring runs overnight perfectly well.
Two honest caveats on the outside stack, because it is not free in the way people mean when they say free. Apify's headline plan price is a budget commitment rather than a ceiling, and the per-result Actor fees are where the real cost sits on high-volume scraping. And n8n needs real setup. A basic workflow is an afternoon. Something with branching, retries and error handling is a project, and it only repays if you will run it repeatedly for a long time.
When the work should stay inside Clay
The honest list, which is longer than it was before March.
| Situation | Where it belongs | Why |
|---|---|---|
| Buying emails, phones and firmographics | Inside Clay | Marketplace prices fell 50 to 90 percent and failed lookups stopped being charged. The 2025 arithmetic against this is stale |
| Under a few thousand records a month, simple tables | Inside Clay | The external stack costs more in setup and maintenance than it saves at that volume |
| Long branching logic, many steps per record | Outside, one call back in | Per-run execution billing beats per-step Action billing as step count rises |
| AI classification or personalisation at volume | Outside, on your own key | The model is cents per thousand records; the AI column is an Action per record on top of it |
| You already hold direct contracts with data providers | Outside for data, Clay for orchestration | Removes the Data Credit meter entirely and leaves only Actions |
| Frequent CRM pushes | Inside Clay, batched | Each push is an Action, so the lever is how often you sync rather than where the sync runs |
| Anything you are still prototyping | Inside Clay | Iteration speed is worth more than unit cost until the workflow stops changing |
The pattern in that table: data belongs inside Clay more than it used to, and orchestration belongs outside more than it used to. Those moved in opposite directions on the same day, which is why the old all-or-nothing framing of hybrid against native does not survive the change.
Should you build your own enrichment infrastructure instead?
We get asked this in its full form, usually by teams who have just modelled their Action spend and did not like the answer: skip Clay, plug real-time data APIs straight into your own pipeline, own the whole thing.
It is a real option and it is not the obvious one. What you are actually buying from Clay, once you strip out the parts you could replicate, is the marketplace: one contract and one integration in front of dozens of providers, with fallback logic between them. Rebuilding that means individual contracts, individual minimums, individual failure modes, and your own waterfall logic to sequence them. Teams that already hold direct provider contracts have paid most of that cost, and for them the case is strong. Teams that do not are usually underestimating it by a wide margin.
The signals that genuinely point at building: you need no per-action metering because your workflows are structurally step-heavy, you run the same pipelines across many clients and want them reusable, you need API access as a first-class thing rather than a plan feature, and your data volume is high enough that provider minimums stop being a barrier and start being a discount. Fewer than all four, and the honest answer is usually a tighter Clay table rather than a build.
What we would not do is decide before running the step count. The same table design that exhausts Actions in Clay tends to be expensive wherever it lands, and rebuilding it somewhere else without fixing it just moves the bill.
Count the operations per record before you count the tools.
Operations per record times records per month is your Action bill. Data pulls per record times records per month is your Data Credit bill. Whichever crosses its allowance first is the only one worth engineering around, and for most teams it is not the one they assumed.
What we run, and what we will not claim
We run the split this page describes: Clay for marketplace data and the table interface, n8n for branching and orchestration, our own Anthropic keys for anything a model can do, and Apify for scraping. We rebuilt the handoffs after March, because the free HTTP call was load bearing in the old design and is not free any more.
The previous version of this page carried before and after numbers for our own credit usage, a headline percentage saving, and a projection of what a team processing fifty thousand leads a month would save annually. None of those had a source anyone could check, including us, so they are gone rather than restated. Everything numerical here is either a published list price or arithmetic on one, and the six-to-one ratio is labelled as our arithmetic because that is what it is.
What we will say from running it: the March change made the hybrid stack a narrower recommendation and a better one. Narrower because buying data outside Clay is now the weaker half of the case, and better because the half that remains, keeping step-heavy orchestration off a per-step meter, is the half that was always doing the work.
Not sure whether your Clay bill is a data problem or a design problem?
Book a free 30-minute call. We will look at your biggest tables, count the operations per record against your plan's allowances, and tell you whether the fix is the table, the plan, or moving the work out. No affiliate links.
Book a Clay audit →If you are earlier than this and still deciding where Clay fits, the case for Clay as a GTM platform covers what it is good at, and the waterfall enrichment guide covers the mechanic most Data Credit spend goes to. If you want the work done rather than explained, that is what our Clay agency practice and our n8n and AI automation work are for.
Sources
Clay's pricing page, its Pricing 3.0 announcement and its Actions and Data Credits documentation are the primary sources for everything here about Clay, and none of them was directly reachable from the environment this page was written in. The figures are therefore credited to the publishers that reported them, and you should check current numbers against Clay directly before making a purchasing decision.
- Clay, Introducing Clay Pricing 3.0, and the Actions and Data Credits documentation at clay.com and university.clay.com
- Plan allowances and the March 2026 change as reported by Cleanlist, Landbase and Salesmotion
- Bitscale on the HTTP API tier move and what the Action allowance means for agencies
- GTM Daily on the community reaction and who was making it
- n8n pricing and execution counting, at n8n.io
- Apify plans and compute unit pricing, at apify.com
- Anthropic model pricing, prompt caching and the Batch API, at anthropic.com