You signed up, saw your free credits in the dashboard, and now you’re wondering what it actually means. How many API calls is that? Will you burn through it in 10 minutes? Why do some APIs cost more than others?
Fair questions. Let’s clear it up.
The Short Version
One credit = one API call. For most APIs, anyway.
Your account has a credit balance. Every successful API request subtracts from it. When you hit zero, requests stop working until you add more credits or your monthly allowance resets.
That’s really it. The rest is details.
Why Credits Instead of Just Counting Requests?
Because not all requests are equal.
Looking up an IP address takes milliseconds. Extracting text from a 50-page PDF? That’s actual work. Running AI inference? Even more.
Credits let providers price fairly. Simple stuff costs 1 credit. Heavy processing might cost 5-10.
| Request Type | Typical Cost |
|---|---|
| IP lookup, email validation | 1 credit |
| QR code generation | 1 credit |
| PDF text extraction | 2-5 credits |
| AI text generation | 5-20 credits |
You’re paying for compute, not just request count.
Token Billing vs. Flat-Rate Subscriptions
This is the question most teams wrestle with early on. The traditional model is simple: pay $99/month, get unlimited access. Clean. Predictable. But it falls apart once you look closer.
Flat-rate pricing means the provider has to assume worst-case usage and price accordingly. That $99/month plan probably supports 50,000 requests. If you only use 2,000, you’re subsidizing heavy users. If you use 200,000, the provider either throttles you or eats the cost.
Token billing fixes the alignment problem. You pay for what you use. Light month? Small bill. Big launch? Bigger bill, but proportional to actual value delivered.
Here’s a real comparison:
| Model | Monthly Cost | Requests | Cost Per Request |
|---|---|---|---|
| Flat $49/mo plan | $49 | ~5,000 actual | $0.0098 |
| Token billing | $12.50 | 5,000 | $0.0025 |
| Flat $49/mo plan | $49 | ~45,000 actual | $0.0011 |
| Token billing | $112.50 | 45,000 | $0.0025 |
At low volumes, token billing wins by a lot. At high volumes, flat-rate can be cheaper — but only if you consistently use most of your allocation. Most teams don’t.
The sweet spot for many developers: start with token billing while you figure out your patterns, then evaluate a subscription once usage stabilizes.
Estimating Your Usage (Before You Commit)
Most teams guess wrong. Here’s how to guess less wrong.
Step 1: Count your user actions, not your users. 10,000 users who each trigger 1 validation per session is different from 500 users who trigger 20 lookups each.
Step 2: Map actions to API calls. A single “verify user” flow might hit email validation, phone validation, and IP lookup — that’s 3 credits per signup, not 1.
Step 3: Account for retries and errors. Your code probably retries failed requests. Budget for 10-15% overhead from transient failures.
Step 4: Don’t forget background jobs. Cron jobs, webhooks, batch processing — these add up silently. A nightly job that validates 50,000 email addresses is invisible in your user-facing estimates but very visible on your bill.
Signups: 500/day × 3 API calls each = 1,500
User sessions: 8,000/day × 1.2 calls avg = 9,600
Background jobs: 2,000/day
Retry overhead: ~15%
Daily total: ~15,065
Monthly: ~451,950 creditsThen add a 30% buffer. Production always has surprises — a viral feature, a bug that retries infinitely, a data migration someone forgot to mention.
What Doesn’t Cost Credits
Failed requests from your end (400-level errors) typically don’t count. You messed up the request — no charge.
Server errors (500-level) definitely shouldn’t count. That’s their problem, not yours.
Requests that never complete due to timeouts? Depends on the provider. Check before assuming.
This matters more than you’d think. A misconfigured client that sends thousands of malformed requests shouldn’t drain your balance. Read the provider’s billing policy on error handling — specifically, which HTTP status codes count as billable. If they charge for 4xx errors, that’s a red flag.
Tracking What You’re Spending
Most dashboards show your balance and recent usage. If you want to track programmatically:
// Check your remaining balance (if the API supports it)
const usage = await fetch('https://api.apiverve.com/v1/account/usage', {
headers: { 'x-api-key': process.env.API_KEY }
}).then(r => r.json());
console.log(`${usage.data.credits_remaining} credits left`);Set up alerts before you hit zero. Finding out you’re out of credits because production broke is a bad morning.
Building a Usage Dashboard
If your team has multiple developers hitting the same API account, raw balance checks aren’t enough. You need visibility into who’s using what, and when.
// Log every API call with metadata
async function trackedApiCall(endpoint, params, context) {
const start = Date.now();
const result = await makeApiCall(endpoint, params);
await logUsage({
endpoint,
timestamp: new Date().toISOString(),
duration: Date.now() - start,
caller: context.service,
environment: context.env,
creditsUsed: result.headers['x-credits-consumed'] || 1
});
return result;
}Track by service, by environment, and by time of day. You’ll quickly spot patterns — like that staging environment burning through credits because someone left load testing on.
Billing Transparency: What to Look For
Not all billing systems are created equal. When evaluating an API provider’s billing model, here’s what separates the good from the frustrating:
Clear credit costs per endpoint. You should know before you call an endpoint exactly what it will cost. If you have to make a request to find out the cost, that’s backwards.
Real-time balance updates. Some providers batch-update balances hourly. That’s fine for accounting, terrible for monitoring. You want to see your balance drop in near-real-time.
Detailed usage logs. Not just “you used 5,000 credits today” but a breakdown by endpoint, timestamp, and status code. When your bill spikes, you need to diagnose why.
Transparent overage pricing. If the provider allows overages, the per-credit cost beyond your plan should be clearly stated upfront. Surprise invoices erode trust fast.
Credit expiration policies. Do unused credits roll over? Do they expire after 30 days? After a year? This changes how you should buy. Rolling credits mean you can buy in bulk safely. Expiring credits mean you should buy just what you need.
Actually Saving Money
Cache responses. IP addresses don’t change location. Validated emails stay validated. Store results and skip duplicate calls. The IP Lookup API is a great candidate for aggressive caching — an IP’s geolocation data stays valid for weeks.
const cache = new Map();
async function lookupIP(ip) {
if (cache.has(ip)) return cache.get(ip);
const data = await fetchIPLookup(ip);
cache.set(ip, data);
return data;
}Validate client-side first. Don’t spend a credit checking if not-an-email is a valid email address. Basic regex catches obvious garbage before it hits the API.
// Cheap client-side check before expensive API call
function quickEmailCheck(email) {
if (!email || !email.includes('@') || email.length < 5) return false;
if (email.startsWith('.') || email.endsWith('.')) return false;
return /^[^\s@]+@[^\s@]+\.[^\s@]+$/.test(email);
}
// Only call the API if basic validation passes
if (quickEmailCheck(userEmail)) {
const result = await validateEmailViaAPI(userEmail);
}This one change typically cuts email validation costs by 15-25%. That’s pure waste eliminated.
Batch when possible. Some APIs let you validate 10 items in one call instead of 10 separate calls. Same work, fewer credits.
Deduplicate before calling. If your nightly batch job processes a CSV with 100,000 rows but only 40,000 unique email addresses, deduplicate first. You just saved 60% of your credits.
Use tiered caching with TTLs. Not all data expires at the same rate. Email validation results are good for months. Currency conversion rates might be stale in an hour. Set TTLs accordingly:
const CACHE_TTLS = {
'email-validation': 30 * 24 * 60 * 60, // 30 days
'ip-lookup': 7 * 24 * 60 * 60, // 7 days
'currency-rate': 60 * 60, // 1 hour
'weather': 15 * 60 // 15 minutes
};Subscription vs Pay-As-You-Go
Two models you’ll encounter:
Monthly subscription: Pay $X, get Y credits that reset each month. Unused credits usually don’t roll over. Good if your usage is predictable.
Pay-as-you-go: Buy credit packs, use until empty. No expiration. Good for sporadic usage or testing.
Most providers (including APIVerve) offer both. Start with free tier, upgrade when you know your patterns.
There’s a third hybrid model gaining popularity: subscriptions with overage billing. You get a base allocation at a discounted rate, and anything beyond that bills at a per-credit rate. This gives you cost predictability with a safety net for traffic spikes.
The wrong choice here can quietly cost you thousands over a year. If you pick a subscription plan sized for your peak month, you’re overpaying most months. If you pick one sized for your average month, you’re paying overage rates during peaks. The solution is monitoring — know your patterns before you lock in.
Real-World Pricing Scenarios
Let’s walk through three actual usage patterns and what they cost:
Scenario 1: Early-stage SaaS (50 signups/day)
Each signup validates an email and checks the user’s IP. That’s 2 credits per signup, 100/day, about 3,000/month. The free tier covers this. You spend $0.
Scenario 2: Mid-stage platform (2,000 active users/day)
Each session involves 2-3 API calls on average. Plus a daily batch job that processes 5,000 records. Total: roughly 11,000 credits/day, 330,000/month. A mid-tier plan handles this comfortably. With caching, you might cut it to 200,000.
Scenario 3: High-volume application (50,000 requests/day)
At this scale, caching strategy matters enormously. Without caching, you’re at 1.5M credits/month. With a well-implemented cache hitting 60% of requests, you’re at 600,000. That difference could be hundreds of dollars a month.
What Happens at Zero
Three possibilities:
- Hard stop — Requests fail with 402 or 429 until you add credits
- Overage billing — Requests continue, you get billed extra
- Grace period — Brief buffer to prevent production outages
Know which one your provider uses. Set up monitoring accordingly.
The hard stop is the safest for your wallet but the most dangerous for your uptime. If your authentication flow depends on an API call and credits run out at 2 AM, new users can’t sign up until someone wakes up and buys more credits.
The practical solution: set alerts at 25%, 10%, and 5% remaining. Automate credit purchases or plan upgrades if your provider supports it. And always keep your most critical API calls on a separate account with its own budget — don’t let a runaway batch job eat the credits your auth flow needs.
Quick Math
Before committing, estimate your costs:
Users: 10,000/day
API calls per user: 3
Daily calls: 30,000
Monthly: ~900,000
At 1 credit per call = 900k credits/monthThen double it for safety. Real usage always exceeds estimates.
Build your cost model in a spreadsheet. Include best case, expected case, and worst case. If worst case is affordable, commit with confidence. If worst case makes your CFO flinch, implement hard usage caps in your code before going to production. Check the rate limits documentation to understand how your provider handles throttling — that’s your last line of defense against runaway costs.
Keep Reading
- Business Day Math Is Harder Than You Think
- 7 SSL Certificate Problems That Kill Trust
- DNS Lookups: A Developer's Debugging Guide
That’s token billing. Simple concept, occasionally confusing terminology. The free tier is enough to build and test — grab your free API key and see how it actually works with real requests.
