GTM Engineering

Credit-based pricing

Credit-based pricing charges for consumption, a set number of credits per plan, spent down as a tool performs actions like an email lookup, a phone-number find, or an AI-run enrichment step, rather than a flat rate per user.

Credit-based pricing ties the bill to what a tool actually does, not to who's logged in. A plan buys a pool of credits, and each action, an email lookup, a phone-number find, an AI research step, spends some of that pool. Run more, spend more. Run less, some of that spend can sit unused.

Credits aren't priced flat within a tool either. FullEnrich's pricing runs $55 a month for 1,000 credits, but a work email costs 1 credit while a personal email costs 3 and a mobile number costs 10, so verifying a batch of mobile numbers burns through a pool far faster than the headline credit count suggests. Clay runs a similar two-currency version of the same idea: Actions for orchestration steps like enrichments, AI uses, and API calls, and Data Credits for the underlying data itself, with different plans bundling different amounts of each.

Not every action costs the same, and the ceiling doesn't move

Clay's own docs draw a hard line worth knowing before budgeting: Actions are a ceiling that doesn't roll over month to month and can't be topped up separately, the only way to get more is a plan upgrade, while Data Credits do roll over and can be bought as one-time top-ups. That distinction means a high-volume build can hit its hard wall on the Actions side long before Data Credits become the binding constraint, no matter how efficiently the credit-heavy part of the workflow runs.

In practice

Treat the credit cost of a workflow as a tuning parameter, not a fixed bill. Which fields you're pulling, which providers you're calling, and how many fallback steps a waterfall runs before it gives up all change what a run actually costs, and none of that shows up on the plan's headline credit number.

What people get wrong

People compare tools by their headline credit price and skip the per-field or per-action cost hiding underneath it. A cheap credit on a field that rarely returns a result can cost more per usable outcome than an expensive credit on a field that almost always finds what it's looking for. Cost per verified result is the number that matters, not cost per credit.

Related terms
Where we use this
Updated July 26, 2026

Ready to engineer your GTM motion?

Tell us how your motion runs today. We'll show you what we'd engineer.

Contact us