Clay's Data Credits vs Actions: What Actually Gates Your Waterfall Cost

Two people can run the same waterfall on the same Clay plan and hit two completely different walls. One maxes out Actions ten days before renewal and is stuck paying for an upgrade they didn't budget for. The other never gets near the Actions ceiling but burns through Data Credits by the third week, and has three ways to fix that before touching their plan at all. Same platform. Same pricing page. Two different failure modes, and most people troubleshoot both the same way, which is why they keep getting surprised.

What changed when Clay split one currency into two

Clay used to run on a single credit pool. That pool got split into two separate meters, Actions and Data Credits, as part of the March 2026 restructure that replaced the old Starter/Explorer/Pro tiers with Launch/Growth/Enterprise. Per Clay's own pricing page and its docs at university.clay.com, the two-meter split is still how the platform works today. Worth saying up front, because it matters for how much weight you put on any number in this piece: Clay could restructure again. Every figure below carries a July 2026 date stamp, which tells you how current the numbers are, not when the split itself happened.

The split isn't cosmetic. It's the difference between a cost you can manage and a cost that manages you, and which one you're dealing with depends entirely on which meter is closer to empty when you check.

Actions vs Data Credits: the mechanical difference

Actions and Data Credits get consumed by different things, refill on different schedules, and fail in different ways when you run out. Confuse them and you'll optimize the wrong lever.

Actions meter Clay's own orchestration

An Action fires for enriching a record from any provider, running a table step, calling an AI model inside a column, sending data out to another tool, exporting to a warehouse, and (this one surprises people) making an HTTP API call, whether that call comes from you or from Clay's own in-table integration. Per Clay's docs, each Action costs a few tenths of a cent depending on plan tier.

Capacity is fixed to whatever plan you're on. It resets every billing cycle. It does not roll over, and you cannot buy more mid cycle no matter how badly you need them. The only lever is a tier upgrade. That's it.

Data Credits meter third-party data

Data Credits buy email addresses, phone numbers, and company details sourced from the 150-plus providers in Clay's marketplace. Per Clay's own docs at university.clay.com/docs/actions-data-credits, a single email or profile lookup runs about 0.5 credits on the low end, and a fully enriched record across several providers can land anywhere from 6 to 20 credits. Some third-party sources quote individual lookup types, phone numbers especially, well above that range. No page on Clay's own site states a per-lookup ceiling in the double digits, so treat any number that specific as the third party's estimate, not Clay's.

Unlike Actions, Data Credits roll over: up to 2 times your monthly allotment on monthly billing, or 15 percent of the unused amount on annual billing, and only if you renew at an equal or higher tier. You can also buy a one-time top-up at a 30 percent premium over your plan rate, or skip the marketplace entirely by connecting your own provider API key. Bring your own key still costs 1 Action for the orchestration step. It costs zero Data Credits, because the provider bills you directly instead of through Clay's marketplace.

Hard cap vs elastic constraint: why the difference is the whole game

Here's the part most pricing explainers skip. Actions are a hard, non-negotiable ceiling inside a billing cycle. You cannot buy your way past it. You can only escalate your tier, and that's a plan-level decision, not a workflow fix. Data Credits are the opposite: an elastic, purchasable, reroutable budget. Rollover, a one-time top-up, and bring-your-own-key all bend that number in different directions before you'd ever need to touch your plan.

Most teams manage Clay spend like there's one dial. There are two, and they break differently under pressure. Hit the Actions ceiling and your only move is an unplanned upgrade, usually discovered at the worst possible moment, mid-sprint, with a client deliverable due. Hit the Data Credit ceiling and you have three moves before an upgrade even enters the conversation: wait for next month's rollover, buy a top-up, or route the expensive provider through your own key.

The diagnostic: which one is actually gating you

Pull your usage page and check which meter is closer to depleted at month end. That's the whole test. Do it before you touch anything else.

Workflows with a lot of steps per record, multi-step AI research chains, long Claygent passes, several sequential table transforms, tend to run Action-heavy. Workflows built around wide, multi-provider waterfalls at high record volume tend to run Data-Credit-heavy. Know which one you actually hit before you "optimize" the wrong side of the ledger. I've watched teams spend a week reordering waterfall providers to save Data Credits when their real problem was an Actions meter drained by an AI research step running on every single row, whether it needed to or not.

How the split should change your waterfall sequencing

When Actions are the binding constraint

The common advice here is to reorder your waterfall providers to save money. I want to flag something before repeating that advice as settled fact: whether every provider attempt inside a waterfall step burns its own Action, or Actions hold flat per column no matter how many providers get tried, is not confirmed anywhere in Clay's own documentation as of this writing. I checked the pricing page, the waterfall-enrichment page, the FAQ, and the actions-and-data-credits doc directly. None of them say it plainly. The way to settle it for your own workspace is Clay's per-column Run Info panel (right-click a column, then Run Info), and until you've checked that yourself, treat provider reordering as a Data Credit tactic first and an Actions tactic maybe.

What holds regardless of how that question resolves: cut redundant table steps. Collapse a five-step AI research chain into two calls if the model can hold the context. Add conditional logic so records that don't need a step skip it, instead of running every row through every column whether it's necessary or not. If your Actions meter is persistently full at month end after you've done that, take it as a signal to upgrade tier. Not a signal to keep re-sequencing something that was never going to move the number.

When Data Credits are the binding constraint

This is where sequencing actually does something. Order your providers cheapest to most expensive so the low-cost sources catch the easy matches first, and the expensive ones only fire on records the cheap pass missed. Filter and qualify your input list before enrichment runs at all. Spending Data Credits chasing contacts you'll never message is the single most avoidable waste in a Clay workflow, and it happens because the enrichment step ran before the list got cleaned, not after.

And connect your own API key for any provider you already pay for outside Clay. That converts marketplace spend, which is capped by your plan's Data Credit allotment and marked up when you top it up, into a straight Action cost you were probably going to pay anyway. This is the same bring-your-own-key trade-off that shows up whenever you compare Clay's marketplace pricing against a direct provider relationship, and it's worth running the math on your top two or three providers specifically, not assuming it's a universal win.

Where teams get surprised

The rollover math is asymmetric in a way that trips people up at renewal. Monthly billing caps your rollover at 2 times the monthly amount, so credits can stack for a couple of cycles before hitting a ceiling. Annual billing only carries forward 15 percent of what you didn't use, and only if you renew at the same tier or higher. Downgrade at annual renewal and whatever would have rolled over is just gone.

Actions running out mid cycle is the other one. There's no partial fix. The only move is an unplanned tier upgrade, and if that happens two weeks before your renewal date anyway, you've paid for capacity you'll re-buy at the higher tier a few weeks later regardless.

Then there's a conflict worth flagging directly: does a failed, no-match provider attempt inside a waterfall still cost you a Data Credit? Clay's own pricing FAQ states it plainly: if an enrichment returns no result, you're not charged Data Credits or Actions. But some community threads and third-party breakdowns, DevCommX's pricing writeup among them, describe the opposite: charged per attempt whether or not the provider found anything. That's a direct conflict between Clay's own stated policy and what some users report seeing in their own usage pages. Test it in your own workspace before you build a cost model around either version.

What we checked at our own renewal

LLP has run Clay on the legacy Explorer plan, the older single-currency structure, since before the March split. At our own renewal point, we sat down and evaluated the newer two-currency plans against what we actually do in Clay. Not because we were shopping around for fun. Staying on a legacy plan without checking the alternative is its own kind of risk, and we'd rather know we made the right call than assume it.

What we looked at: whether our own workflow mix runs Action-heavy or Data-Credit-heavy using the diagnostic above, whether our existing provider relationships would offset marketplace spend through bring-your-own-key, and whether the newer plans' rollover and top-up flexibility would have caught the specific budget surprises we've hit under the legacy model.

We stayed on the legacy Explorer plan. At our current workflow mix and volume, it still beats the newer two-currency structure, which matches what we've said elsewhere about our own Clay setup. That's a decision from one renewal cycle, evaluated against our own usage pattern. It's not a claim that we're running the new plans day to day, because we aren't.

A checklist before your next renewal or plan upgrade

Start with your own usage history, not a guess. Pull the last three months of the usage page and note which meter, Actions or Data Credits, actually depletes first each cycle. Sort your waterfalls into Action-heavy and Data-Credit-heavy buckets using the diagnostic above, because the fix looks completely different depending on which bucket a given workflow lands in. Audit your top two or three data providers for bring-your-own-key eligibility, since that's the one lever that works on Data Credits regardless of plan tier. Confirm which rollover rule actually applies to your billing cadence before you assume last cycle's leftover credits are sitting in your account; monthly and annual behave differently, and the difference is exactly the kind of thing people find out the hard way at renewal. Price out a one-time top-up against a full tier upgrade before you're forced to choose one of them under deadline pressure, because doing that math calmly in advance beats doing it in a panic when a campaign is mid-flight. And re-verify Clay's current numbers directly against clay.com/pricing before you act on anything above; the pricing table has already changed once this year, and several third-party "Clay pricing explained" posts found in a general search attribute Growth's Actions and Data Credit figures to the Launch tier instead, most likely because they misread Clay's own pricing table rather than because Clay's page itself is inconsistent. Clay's own page, checked directly, doesn't have that problem. The blog posts repeating the mixed-up numbers do.