API pricing strategies: flat, tiered, prepaid credits, success-based

You can rewrite a pricing page in an afternoon. You cannot rewrite a meter in an afternoon.

That asymmetry is the part every API pricing strategy article skips. They hand you a taxonomy of models, tell you to align price with value, and stop exactly where the work starts: the model you pick decides what your code has to count, and when it is allowed to count it. Flat pricing and success-based pricing are not two points on one spectrum. They are two different programs.

So this is the survey with the engineering attached. Four models, priced against rate cards read this week, each with the counter it forces you to build and the customer complaint it generates. Then a section on success-based pricing, which is the most fashionable option in 2026 and the one whose bill you cannot issue until after you have already spent the money.

The four models, with real prices

Every figure below came off the vendor's own pricing page this week. Prices move, so re-read them before you quote them anywhere that matters.

Model	You bill for	When you charge	Real published example	Its actual weakness
Flat	Access, for a period	Up front, before any traffic	Treblle Core: $233/mo billed yearly, capped at 500 requests/min, 30-day retention, up to 5 APIs	Your heaviest customer's marginal cost is unbounded unless you hide a limit in the plan
Tiered	An allowance of units per month	Up front, then count against the allowance	ReqKey: $25 at 500K requests rising to $500 at 50M. Unkey API Management: $25 at 250K valid requests rising to $1,000 at 100M	Everything interesting happens at the boundary, and the boundary is a product decision you cannot avoid
Prepaid credits	A balance, spent per operation	Before the work, by deducting	Firecrawl: 1,000 credits free, up to $599/mo for 1,000,000 credits (billed yearly). Tavily: $0.008 per credit pay-as-you-go	You now owe the customer a per-operation price table, and you must publish what a failure costs
Success-based	A defined outcome	Only after the outcome is known	Stripe: 2.9% + 30¢ per successful transaction for domestic cards. Intercom Fin: $0.99 per outcome	You cannot pre-authorise anything, so you carry the cost of every attempt that fails

Notice that the "when you charge" column is the only one that changes the shape of your code. The rest is arithmetic.

Flat: the model with a rate limit hiding in it

Flat is the easiest thing to sell. One number, no calculator on the pricing page, no anxiety in procurement. It is also the only model where a single customer can quietly become unprofitable without anything in your billing system noticing.

Which is why almost no flat plan is actually flat. Treblle's Core plan is the honest version of this: it prices at a fixed $233/mo (billed yearly) and puts the constraint in 500 Requests / min. That is a throughput ceiling, not a monthly allowance, and it is a genuinely different unit. A customer doing 500 requests per minute continuously and a customer doing one big nightly batch can sit on the same plan with wildly different monthly volumes, and neither of them can compare that plan to a per-million rate card without doing conversion work first.

Every flat plan is a usage plan with the meter moved into the terms. The meter still exists. You just decided not to show it to the customer, which means you also decided not to show it to your finance team.

Do I still need per-customer metering if I charge flat?

Yes, and this is the trap. If you do not meter per customer, the first time you learn which account is eating your margin is when you read your own infrastructure bill, aggregated, a month late, with no way to attribute it. Meter from day one and keep the numbers private. Flat pricing is a decision about your invoice, not about your instrumentation.

Tiered: the ladder almost everyone ships

Tiered pricing wins by default for most APIs because it gives the customer a bounded bill and gives you a per-unit price that falls as volume rises. The falling part is the whole pitch, and it is easy to verify because you can just divide.

Firecrawl's self-serve ladder, derived by dividing each plan's monthly price by its included credits:

Plan	Price (billed yearly)	Credits/mo	Derived cost per credit
Free	$0	1,000	$0
Hobby	$16/mo	5,000	$0.0032
Standard	$83/mo	100,000	$0.00083
Growth	$333/mo	500,000	$0.000666
Scale	$599/mo	1,000,000	$0.000599

From the cheapest paid rung to the largest, that is a 5.3x decline in the effective unit price. Unkey's API Management ladder does the same thing in a different currency: dividing its published rungs gives roughly $100 per million valid requests at the bottom and $10 per million at the top, a 10x spread. ReqKey publishes its own version of the table, from $50 per million at the entry tier down to $10 per million at 50M.

Your buyer is going to do exactly this division. Publish the result yourself, because a ladder that does not get cheaper per unit as it climbs reads as a punishment for growing.

The tier boundary is the actual design

Here is the part that is engineering, not pricing. A tier is an allowance, an allowance has an edge, and there are only three things you can do when a customer reaches it.

1. Hard stop. Return 402 or 429 at the line. The bill is perfectly predictable and the product is broken at the worst possible moment, which is the moment your customer is succeeding.
2. Bill the overage. Keep serving and charge per extra unit. Nothing breaks, and you have introduced the invoice nobody budgeted for. This is where usage-based billing earns its reputation for surprise bills.
3. Absorb and ask. Keep serving, do not bill the excess, and open an upgrade conversation. The customer is never broken and never surprised, and you eat the cost of the overage.

ReqKey takes the third one, which is worth stating plainly because it has a real cost to us. The pricing page's commitment is that "anything we accept past your allowance is never billed" and that we "don't hard-stop your traffic at the line." That only works while the ladder has enough rungs that moving up is a small step, and it means we are betting on the upgrade conversation rather than on the overage line item. If your ladder jumps 10x between tiers, option 3 becomes charity.

Whichever one you pick, tiering also hands you the mid-cycle change problem: a customer upgrades on day 14 and your counter has to not double-charge them or silently wipe what they already paid for. That needs a published answer, not an internal one. ReqKey's is that tier changes apply instantly, the billing date resets to that day, and on upgrades unused requests from the old allowance carry into the first month up to the new tier's allowance. You may pick different rules. You may not skip picking.

Prepaid credits: a ledger with three unavoidable policy calls

Credits are the only model where you hold the customer's money before you do the work. That is a strong position, and it is why credit pricing spread through the AI API wave: it converts a lumpy, per-operation cost structure into one number the customer can watch go down.

It also hands you three questions you cannot leave undecided, because your customers will discover your answer empirically if you do not publish it.

1. What is one credit worth? There is no market standard. Tavily sells credits at $0.008 each pay-as-you-go, falling to $0.005 on its largest monthly plan. Firecrawl's Scale plan works out to about $0.000599 per credit. That is more than a 10x gap between two credit-priced APIs, so the unit means nothing until you define it. If credits are new to you, start with what API credits actually are; for the costing exercise itself we wrote up how to decide what one credit is worth, including why your worst route's margin is the only one that survives a change in traffic mix.

2. Do unused credits survive the month? Firecrawl answers this in one sentence: "Credits do not roll over on self-serve plans. Credit rollover is available on our Scale and Enterprise plans." Read that again, because it is a pricing decision wearing a ledger flag's clothing. Rollover is being sold as a feature. That is a legitimate move, and it is only legitimate because they wrote it down.

3. What does a failed request cost? Tavily publishes that a failed URL extraction and a failed map request are never charged. Whatever you choose, choose explicitly. We went deep on the reconciliation problem this creates in your credit system bills before it knows the request worked.

Then there is weighting. A credit system only earns its complexity if different operations cost different amounts, which means publishing a table. Tavily's is a good model of the genre: a basic search costs 1 credit, an advanced search 2, extraction 1 credit per 5 successful extractions, mapping 1 credit per 10 pages. It also shows the failure mode, because its Research endpoint is published at 4 to 110 credits for the mini version. That range is honest and it is unbudgetable. Nobody can plan against a 27x spread on one endpoint, so if your costs really do vary that much, either charge for the sub-operations so the total is derivable, or quote before you execute.

The primitive that makes credits work

Deducting a variable amount is the easy part. The useful part is being able to ask "would this be allowed?" without spending anything. On ReqKey the credits field on validation is a number rather than a flag, and 0 means check without deducting:

# Pre-flight: is this key allowed to do the work at all? Costs nothing.
curl -X POST "https://api.reqkey.com/key/validate" \
  -H "Authorization: Bearer reqkey_xxx..." \
  -H "Content-Type: application/json" \
  -d '{
    "key": "prod_A1B2C3D4E5F6G7H8I9J0K1L2",
    "credits": 0,
    "resource": "/v1/enrich"
  }'

Response (200 OK), with the balance untouched:

{
  "valid": true,
  "requestId": "abc123xyz",
  "creditsRemaining": 9995,
  "creditsLimit": 10000,
  "allowedApis": ["*"],
  "resource": "/v1/enrich"
}

Charging the real cost afterwards is a second call with a real number. Which raises the obvious objection, and it is the right objection:

async function chargeAfterWork(key, credits, resource) {
  const res = await fetch("https://api.reqkey.com/key/validate", {
    method: "POST",
    headers: {
      "Authorization": `Bearer ${process.env.REQKEY_ROOT_KEY}`,
      "Content-Type": "application/json",
    },
    body: JSON.stringify({ key, credits, resource }),
  });

  if (res.status === 402) {
    // Work is already done. The customer ran out mid-flight.
    const body = await res.json();
    console.warn("under-billed", resource, body.creditsRemaining);
    return { charged: false, reason: "insufficient_credits" };
  }
  if (!res.ok) {
    // Never fail the customer's request because metering had a bad day.
    console.error("metering failed", res.status);
    return { charged: false, reason: "meter_unavailable" };
  }
  return { charged: true, ...(await res.json()) };
}

Expected behaviour: on a healthy call you get { charged: true, valid: true, creditsRemaining: ... }. On an exhausted balance you get 402 with "message": "Credit limit exceeded", and you have already done the work for free. That is not a bug in the API, it is the shape of charging after the fact, and it is exactly the exposure the next section is about. The mitigation is boring and effective: size your zero-cost pre-check against the worst case, not the average one.

Success-based pricing: you cannot bill until you already spent the money

Success-based pricing (also sold as outcome-based pricing) charges for a result instead of a request. It is the most credible answer to a real customer objection, which is that a request is a proxy for value and sometimes a bad one. Three published examples, all of them real:

• Stripe charges 2.9% + 30¢ per successful transaction for domestic cards. Declined charges are not billed. This is the oldest and cleanest outcome price in software, and it works because "the payment went through" is not a matter of opinion.
• Intercom prices its Fin agent at $0.99 per outcome, and publishes what counts: the customer confirms the issue is resolved, or they do not ask for more help after Fin responds, or Fin completes a workflow including handoffs. You are charged once per conversation even if several questions get answered.
• Zendesk publishes the principle and the unit without a per-unit price on its pricing page: AI agents are billed on "Automated Resolutions," and you "pay only for customer requests that were successfully resolved by the AI agent, without any escalation to a human agent."

Now the part that is missing from every article that recommends this model.

Success-based pricing does not replace usage metering. It adds to it.

Every other model lets you charge at or before the gate. Prepaid credits let you refuse a request before you spend a cent of compute, because the balance was already deducted. Tiered lets you count at the door. Flat charged you last month.

Success-based inverts that. The billable event is only observable after the expensive work has finished, so there is no moment at which you can pre-authorise. Which means:

• A client can consume unbounded compute before you find out they cannot pay for any of it.
• Your abuse surface stops being revenue and becomes cost. Someone who can make your system attempt and fail forever costs you money at no risk to themselves.
• You therefore need a second, non-billable meter counting attempts, purely to protect yourself, plus the outcome detection you built to invoice with.

So the honest framing is that outcome pricing is usage metering plus outcome detection plus a rate limit, not a simpler alternative to any of them. Anyone who tells you it reduces your billing complexity has not shipped it.

The arithmetic that decides whether it can work at all

One formula does most of the work here. Your revenue per attempt is your price per outcome multiplied by your success rate:

revenue per attempt = price per outcome × success rate

Your cost per attempt does not care about your success rate. It is the same whether the attempt lands or not. So your break-even cost per attempt is price × success rate, and it moves linearly with a number that is partly outside your control. At Intercom's published $0.99:

Success rate	Revenue per attempt	Max you can spend per attempt before losing money
80%	$0.792	79.2¢
60%	$0.594	59.4¢
40%	$0.396	39.6¢
20%	$0.198	19.8¢

Read the third column as the hard constraint it is. At a 60% success rate and a 99¢ outcome price, every single attempt must cost you under 59.4¢ just to break even, before any margin at all. That number is not on your pricing page and your customers will never see it, but it is the number that decides whether the model survives contact with a hard customer segment. A cohort where your success rate is 20 points lower is not 20% less profitable. It can be unprofitable outright while every dashboard still shows the same 99¢ price.

Spoiler: the hard segments arrive first, because the customers with the messiest problems are the ones most motivated to try a tool that only charges when it works.

Who decides the outcome happened?

This is where success-based pricing goes wrong in practice, and Intercom's published conditions are the model to copy: three specific, checkable events, and one charge per conversation. Compare that to "pay for results" with no definition attached, which is a support ticket generator.

The test I would apply before shipping any outcome price: if you cannot write the billable condition in one sentence that a sceptical customer would accept without arguing, you do not have a billable outcome yet. You have a marketing line.

Partial success is the genuinely unsolved case. The AI resolved the ticket, then the customer came back three days later. The enrichment returned 6 of 10 fields. There are three workable exits and no clever one: define success strictly and accept that you under-bill, define it loosely and accept the disputes, or split the operation into sub-outcomes that are each individually unambiguous and charge for those. Pick before launch, because changing it later reads to customers as a price rise.

If you want the commercial side of this argued well, Madhavan Ramanujam's episode on pricing AI products is the best single hour on how much of the value you created you can actually capture:

What a failed request costs, according to four vendors who publish it

Here is the question that exposes whether a pricing model has actually been thought through, and there is no industry default. Four providers, four incompatible published answers:

Provider	Published rule on failures	What that implies
YouTube Data API	"All API requests, including invalid requests, incur a quota cost of at least one point."	The quota protects the platform, not the caller. A bad client burns its own budget.
Tavily	Failed URL extractions and failed map requests are never charged	The provider absorbs its own failures, and must therefore rate-limit separately
Unkey	Billed on valid requests per month, with invalid and rate-limited requests excluded	Rejections are free to the customer, which makes the billing unit match the value
Stripe	2.9% + 30¢ per successful transaction; declines are not billed	Pure outcome pricing, viable because the outcome is objectively observable

Four vendors, four answers, all defensible. That is what "no default" looks like, and it is why this belongs on your pricing page rather than in your issue tracker.

For what it is worth, ReqKey's answer comes from ordering rather than from a refund policy: the credit check runs last in validation, so a request rejected for a missing key, a disabled key, a disabled consumer or an expired key never reaches the deduction. A rate-limited request consumes no credits and no rate-limit quota either, so a throttled client recovers by slowing down. Free by construction beats free by reimbursement, mostly because reimbursement requires you to have built a refund path, and almost nobody does.

How to choose an API pricing strategy

Not a matrix. A path, in order.

• Is your marginal cost per call near zero and roughly constant? Flat, with a ceiling you publish honestly instead of hiding in the terms. Meter privately anyway.
• Does cost scale with volume, and is the unit obvious to a customer without explanation? A tiered ladder with a per-unit price that visibly falls. This is the right default for most APIs, and the boundary policy is the real decision, not the tier prices.
• Does cost vary a lot per operation, or do you want cash before you do work? Prepaid credits, with a published per-operation table, a published expiry rule, and a published failure rule. Three sentences, all mandatory.
• Is there exactly one event both sides would agree is the win, and can you detect it without a human in the loop? Success-based. If either half of that is a maybe, the answer is no, and a hybrid gets you most of the appeal: a platform fee plus a metered unit, with the outcome as an upside line rather than the whole rate card.

Most APIs end up hybrid. That is not a failure of nerve, it is what happens when you price the thing you can measure and keep the thing you cannot as a story you tell in the sales call.

Key takeaways

• Your pricing model is a schema, not a slide. It fixes when in the request lifecycle you are allowed to charge, and that single constraint decides your enforcement design. Choose it with an engineer in the room.
• Meter per customer regardless of what you charge. Flat pricing is a decision about the invoice, not about instrumentation. Without per-account metering you discover your unprofitable customer from an aggregated infra bill, a month late.
• The tier boundary is the product. Hard stop, bill the overage, or absorb and ask. Every tiered API answers this, and the ones that never decided answer it by accident during an outage.
• Success-based pricing is additive, not simplifying. It needs outcome detection plus attempt metering plus a rate limit, because you cannot pre-authorise a bill you can only calculate afterwards.
• Run the break-even number before you promise an outcome price. Break-even cost per attempt equals price per outcome times success rate. At 99¢ and 60%, every attempt has to cost under 59.4¢, and a segment 20 points worse can be a loss while the price on your site never changes.

Metering it

Whichever model you land on, someone has to count the units, enforce the ceiling, and tell you who used what. That is the layer ReqKey is: API keys, per-consumer credit balances with refill and overage rules, rate limits as an independent axis, and per-key traffic analytics. Variable per-operation costs are the credits number on a validation call, and a plan's pricing block keeps your rate card sitting next to the limits it describes so the two cannot drift apart.

One scope note so nothing is oversold: ReqKey meters usage and enforces limits. It does not invoice your customers, and the pricing block on a plan is informational rather than enforced. It is the counter and the gate, and your billing system stays yours.

The free tier is 100,000 requests a month with no credit card, which is enough to model a real credit table against real traffic before you commit to a rate card. The docs have the endpoints, and if you are choosing between vendors, our costed comparison of six key-management platforms prices one fixed workload across all of them, ReqKey included.