Credits (API)

How API credits work

API credits turn usage into a ledger. Instead of negotiating a custom invoice for every field or seat, the buyer prepays for a pool of units and the seller deducts from that pool as endpoints run.

Stripe frames credits-based pricing as customers prepaying for credits they redeem across products or services, and it explicitly lists APIs and data services among the businesses that price this way 1. Moesif separates prepaid from postpaid and from pure pay-as-you-go. Prepaid answers when the customer pays, usage-based answers how price is calculated, and many modern APIs combine both as prepaid usage billing 2.

A credit system needs three published facts.

• The credit unit. What one credit represents on paper, even if different endpoints burn different amounts.
• The rate card. How many credits each endpoint costs, and whether billing is per call or per result returned.
• The miss rule. Whether an empty or failed lookup still spends credits.

RichAPI's pricing page states the model in those terms. Bundles are one-time purchases whose credits never expire. Sandbox accounts start with 100 credits and no card 3. Starter, Growth and Scale publish fixed credit counts, and every endpoint lists a credit rate with a per-call or per-result billing model 3. Inquiry and usage endpoints stay free 3.

Miss rules matter as much as list prices. On RichAPI, waterfall email and phone lookups that find nothing settle at zero credits with billed false 3. Profile and company enrichment bill on any 2xx response, including a thin empty body 3. Teams that forecast with the wrong miss rule blow the budget or under-buy the bundle.

Credits are not quality. Spending a credit on a stale title still ages under data decay. Pair credit spend with match rate so finance sees usable outcomes, not raw call counts. Waterfall enrichment is one pattern whose cost depends on those miss rules, while single-source data enrichment calls usually bill on the HTTP success path.

Finance partners understand credits faster when ops shows three columns on one sheet covering starting balance, credits spent by endpoint and verified outcomes produced. Without the third column, a declining balance looks like waste even when the pipeline is healthy.

Agencies and multi-brand teams should split production and experimental pools. Pilot endpoints and one-off research pulls belong on a labeled sandbox balance so a curious test cannot empty the bundle reserved for the quarterly import 3.

How to budget API credits without guessing

Start from the job, not from the largest bundle.

Count the rows that will actually run this month. Multiply by the published credits per billable outcome for the endpoint in the runbook 3. For miss-free waterfalls, multiply by a measured hit rate instead of assuming every row bills 3. For 2xx-billed enrichment, assume every attempted row can bill 3.

Add verification or follow-up calls when the path chains endpoints. An email-to-profile path that needs two calls spends two line items.

Prefer never-expire prepaid balances when volume is spiky. RichAPI states bundle credits never expire, which fits irregular campaign calendars better than monthly allowances that vanish unused 3.

Protect a sample budget. The 100 free sandbox credits exist so a team can prove response shapes and hit rate before buying Starter or Growth 3.

Watch auto top-up. RichAPI describes auto top-up as opt-in and capped by the customer 3. Leaving it off until anomaly alerts exist prevents a stuck loop from emptying a paid bundle overnight.

Report credits per verified outcome next to B2B contact data quality metrics. That is the unit leadership can compare across providers without arguing about raw call volume.

Keep a rollback plan for bad enrichments. If a provider ships stale titles into a bulk pass, snapshot fields before write on large cohorts so the team can revert without replaying every credit.

Example of budgeting API credits for a bulk email pass

Ops plans to find work emails for a conference list of one thousand rows using RichAPI email finder at 5 credits per successful waterfall hit 3.

List size              1,000 rows
Measured sample hit    60 percent
Expected billed hits   600
Credits per hit        5
Expected finder spend  3,000 credits
Misses                 billed false, zero credits
Next                   verify hits, then sequence only valid addresses

They spend part of the 100 free sandbox credits on a frozen sample first 3. Actual hit rate lands near the sample, so finance buys a Growth-sized bundle against that formula rather than against list size times the full list price. Receipts that show billed false on misses are what make the audit match the forecast 3.

If the team later adds profile enrichment at 1 credit per 2xx call, that line is forecast separately because empty bodies can still bill 3. Keeping waterfall and single-source lines apart stops waterfall enrichment math from hiding enrichment overspend.

A second scenario is pure profile enrichment at 1 credit per 2xx call with no free miss 3. For the same one thousand rows the forecast is up to one thousand credits even if half the payloads are thin. That is why the miss rule belongs in the budget template before anyone clicks purchase.

API credits vs waterfall enrichment

API credits are the billing unit. Waterfall enrichment is a lookup pattern whose cost depends on how those credits are charged on each step.