Per-Call or Per-Seat? How to Compare API Pricing Models

Two vendors quote you $90 a month. One bills per API call, one bills per seat, one sells you a block of concurrency. At today's volume the three invoices are within a few dollars of each other, so the decision gets made on the feature matrix. Eighteen months later one of those invoices is still $90, one is $340, and one is $1,900 — and nobody changed their mind about anything. The volume just grew.

The takeaway: the price you compare is a snapshot, but the pricing mechanism is a slope. Two plans that cost the same today can diverge by an order of magnitude at three times your volume, and which one wins depends entirely on which of your numbers is growing. Before you compare prices, work out what each vendor is actually metering — then run every candidate through the same growth scenario.

The three mechanisms, and what each one is really charging for

This applies to any usage-billed service, but APIs are where it bites hardest: consumption grows in step-changes, and one new automated workflow can triple your call count overnight. Almost every pricing page you will meet is one of these three, or a blend.

The distinction that matters is what the vendor has to buy more of when you use more. Metered pricing usually reflects a real marginal cost per unit. Seat pricing rarely does — it is a proxy for how much value your organisation extracts, which is why it tracks your headcount and not your usage. Capacity pricing reflects infrastructure reserved for you whether you use it or not. That is not a ranking: each mechanism is honest about a different thing, and each is the cheap option for a differently shaped buyer.

The three-times test

Here is the whole method, and it takes about twenty minutes per candidate.

1. Write down your current number for whatever each vendor meters — calls per month, active users, peak concurrent jobs. Not your plan limit; your actual number, from last month's data.
2. Multiply by three. Not because you will definitely triple, but because 3x is far enough out that the mechanisms separate visibly and close enough to be a plausible eighteen-month outcome.
3. Price every candidate at 1x and at 3x using their published tiers, including the tier jump. Write both numbers down.
4. Ask what happens between the tiers — see the questions below. This is where the real answer lives.
5. Divide the 3x cost by the 3x value, in whatever unit the purchase exists to produce: cost per ticket resolved, per campaign sent, per monitored endpoint.

The step people skip is the fifth one. A number that stays flat or falls is a mechanism that scales with you; a number that climbs is a mechanism you will be renegotiating. A bill that triples is fine if the output tripled with it — a bill that triples while output grows 40% is the one that ends in a migration project.

A worked shape

Say Option A bills $0.002 per call with no floor, Option B is $30 per seat per month, and Option C sells $90 blocks of capacity. You currently make 15,000 calls a month across a team of three.

• 1x: A costs $30, B and C cost $90. B and C look expensive.
• 3x volume, same team: everything ties at $90.
• 3x volume and the team grows to eight: A $90, B $240, C $90.
• 10x volume, team of eight: A $300, B $240, C still $90 — provided the extra calls fit inside the same concurrency ceiling, which they do if the work spreads across the month rather than arriving in one burst.

Nothing there is a verdict about real products; the point is the shape. Metered pricing tracks your usage, seat pricing tracks your hiring, capacity pricing tracks your peak. Ask which of your three numbers is growing fastest and you have your answer before reading a single feature list.

The questions that decide it

Pricing pages tell you the tier prices. These tell you the mechanism.

For metered plans

• What exactly counts as a billable unit — a request, a successful response, or every retry? For polling APIs, does each poll bill separately?
• Is there a monthly minimum underneath the usage, and what is the overage rate above the allowance?
• Do unused units roll over, or expire monthly?
• Can you set a hard spend cap, and what happens when you hit it — throttling, or a stopped service?

For seat plans

• What is a "seat" — a login, a licence you can reassign, or a concurrent session?
• Can you remove seats mid-term, or only at renewal? (Adding is always instant. Removing is where the contract shows its teeth.)
• Are there cheaper read-only seats for people who only need reports?

For capacity plans

• What is the unit reserving — threads, workers, requests per second — and how does queueing behave when you exceed it?
• Is there any per-unit charge on top, or is capacity genuinely all-inclusive?
• How fast can you scale up and back down, and is downgrading allowed mid-cycle?

Across all three: what is the renewal rate versus the first-term rate, and what does the exit look like? Those two questions belong in every software purchase, and the general framework for asking them is in our software buying process guide.

Where the mechanism hides in the integration

Sometimes you cannot tell which mechanism you are buying until you look at how the API works. Polling protocols are the clearest example: you submit a job, then poll for the result until it is ready.

The legacy 2Captcha-style protocol, implemented by several CAPTCHA-solving services, has this shape. CaptchaAI is one of them, and a useful example because it prices the workload by capacity rather than per call.

curl -s -X POST "https://ocr.captchaai.com/in.php" \
  -F "key=YOUR_API_KEY" \
  -F "method=userrecaptcha" \
  -F "googlekey=SITE_KEY" \
  -F "pageurl=https://example.com/qa-fixture" \
  -F "json=1"
# {"status":1,"request":"2122988149"}

# 2. Poll every ~5s until the result is ready
curl -s "https://ocr.captchaai.com/res.php?key=YOUR_API_KEY&action=get&id=2122988149&json=1"
# {"status":0,"request":"CAPCHA_NOT_READY"}
# ...then eventually:
# {"status":1,"request":"03AGdBq26..."}

Count the HTTP requests in that exchange: one submit, then a poll roughly every five seconds until the job completes. On a solve type the vendor publishes as taking under 60 seconds, a single logical unit of work can be a dozen or more HTTP calls. Under a strict per-request meter your bill is driven by your polling loop as much as by your workload — an engineer tightening a retry interval can move your invoice without touching your throughput.

CaptchaAI's published model sidesteps that arithmetic by selling concurrency instead: you buy simultaneous threads, with unlimited solves per thread, no per-CAPTCHA charge, no daily cap and no surcharge by type. Its published ladder runs BASIC at $15/month for 5 threads, ADVANCE at $90/month for 50, ENTERPRISE at $300/month for 200 — with the effective rate it quotes falling from around $0.09 per 1,000 at ADVANCE to around $0.030 per 1,000 at ENTERPRISE. Those are the vendor's own published figures, not our measurements; treat any vendor's per-unit maths as a claim to verify against your own trial data.

The lesson is the general one, not the specific vendor: under capacity pricing your cost question changes from how many operations will we run? to how many will we ever run at the same time? — and those two numbers can differ by a factor of a hundred for the same workload. Jobs that arrive in an overnight batch make capacity expensive per useful hour. Jobs that arrive steadily make it the cheapest of the three mechanisms, and the only one with a predictable invoice.

Since this category attracts misuse, worth stating plainly: the legitimate uses are QA automation against your own properties, accessibility testing, uptime monitoring, and lawful data collection that respects robots.txt, rate limits and terms of service. Anything aimed at defeating authentication or creating accounts en masse is out of scope here, and out of scope of any serious vendor's acceptable-use policy.

Turning the numbers into a decision

Once you have 1x and 3x costs, do not just pick the smallest number. Score the shortlist on five stated criteria, weighted for your situation: cost at 3x (the number from the test), predictability (how confidently you can forecast next quarter's invoice), downside protection (spend caps, throttles, the ability to shrink), alignment (does the bill grow with the value you get, or with something incidental like headcount), and exit cost (contract length, data export, re-integration effort).

The weights follow from your situation. A fixed budget means predictability above raw cost, which usually lands on capacity or a flat tier. Genuinely unpredictable usage means downside protection, which usually lands on metered with a hard cap. Headcount growing faster than usage makes per-seat the expensive option even when it is currently the cheapest.

FAQ

Is usage-based pricing always cheaper than per-seat? Only while your usage is low relative to your headcount. The crossover point is real and calculable: divide the seat price by the per-unit price to get the number of units per person per month at which they tie, then compare that to your actual per-person usage. Do the division before you assume.

How do I estimate 3x volume if we have no history? Use the trial. Run a representative workload for two weeks, measure actual units consumed, and extrapolate — then ask the vendor what accounts with your profile typically consume. A vendor who cannot answer that is telling you something about how well they know their own product.

What if a vendor won't publish pricing at all? Treat "contact us" as a signal that price depends on what they think you can pay. Get a written quote with the mechanism spelled out — unit definition, overage rate, renewal rate — before you invest engineering time in an integration. The integration is the leverage you are giving away.

Are annual commitments worth the discount? Only when the mechanism is one you have modelled at 3x and are confident about. A 20% annual discount on a plan you will outgrow in five months is not a discount; it is a switching cost you paid for in advance. And note that the cheapest mechanism should decide your shortlist, not your purchase — once two or three candidates land within a reasonable band at 3x, reliability, documentation and support behaviour matter more than the remaining gap.

The bottom line

Compare mechanisms, not prices. Identify what each vendor meters, model every candidate at three times your current volume including the tier jumps, divide the resulting cost by the resulting value, and ask the unit-definition and downgrade questions before signing. When you reach the vendor-by-vendor stage, Bettaso's side-by-side comparisons and pricing tables are built for exactly that step — and we earn an affiliate commission when you buy through them, which never changes a score or an order.

And for the concurrency-priced example above, CaptchaAI's thread-based tiers are a clean illustration of the general move: run a real trial workload, measure your peak concurrency rather than your total volume, and you will know which of the three mechanisms is on your side.