Zuplo supports four billing models, each targeting different business needs. You can mix models on the same pricing page and even within the same plan.
Fixed monthly quotas
The most common API monetization model. The customer pays a flat monthly price
and gets a fixed number of requests (or other metered units). When the quota is
exhausted, the API returns 403 Forbidden until the next billing period.
When to use: Predictable revenue, simple to explain, works for most B2B SaaS APIs.
How customers experience it: They subscribe, get their API key, and use the API until their quota runs out. Clear and predictable for budgeting.
Example: Three-tier SaaS pricing
Free tier:
Code
Starter — $29/mo, 10,000 requests:
Code
Pro — $99/mo, 100,000 requests:
Code
Stripe behavior: Subscription created with a fixed-price line item. Payment charged in advance at the start of each billing period.
Pay-as-you-go
Coming Soon
Pay-as-you-go billing is supported by the underlying monetization models, but the developer portal pricing table experience has not been fully tested for this billing model yet. If you need pure pay-as-you-go pricing, contact support to discuss your use case.
No upfront commitment. The customer provides a credit card, uses the API as much as they want, and is billed monthly in arrears for actual usage.
When to use: Low barrier to entry, usage-based AI APIs, developer tools where usage is unpredictable.
How customers experience it: They sign up, add a payment method, and only pay for what they use. No quota limits, no hard caps.
Example: Per-request billing
Code
Setting isSoftLimit: true with no issueAfterReset means there is no included
quota and no hard limit — everything is billed per-unit.
Example: Graduated per-request billing (volume discount)
Code
Stripe behavior: Subscription with usage-based billing. Usage is tracked continuously and billed through the integrated billing system at the end of each period.
Risk consideration: Pay-as-you-go means you're extending credit. If a customer racks up significant usage and their card declines at invoicing time, you absorb the loss. Consider setting a hard entitlement limit as a spending cap if this concerns you.
Monthly quotas with overages
A hybrid model combining the predictability of fixed quotas with the flexibility of usage-based billing. The customer pays a fixed monthly price for a base allowance. If they exceed it, overage is billed per-unit in arrears.
When to use: Enterprise APIs, weather data services, any API where you want guaranteed revenue with upside on heavy usage.
How customers experience it: They get a known base cost for budgeting, with the ability to burst beyond their quota without service interruption.
Example: Enterprise API with overage
Overage is modeled as graduated tiered pricing. The first tier covers the included allowance at a flat price, and subsequent tiers charge per-unit for overage:
Code
$499/month for 1,000,000 requests. Requests beyond 1M are billed at $0.05 each. A customer using 1,200,000 requests pays $499 + (200,000 x $0.05) = $499 + $100 = $599.
Example: Graduated overage pricing
For high-volume APIs, you might want overage pricing that decreases at scale:
Code
Stripe behavior: Subscription with both a fixed-price component (advance payment) and a usage-based component (arrears). Usage is tracked and billed through the integrated billing system.
Credits / tokens (prepaid)
Customers buy credit bundles in advance. Each API call (or token, or byte) consumes a defined number of credits. When credits are exhausted, service stops until the customer tops up.
When to use: AI APIs, marketplaces, any service where customers want to buy in bulk at a discount and burn down over time.
How customers experience it: They buy a credit pack, use the API until credits run out, then buy more. No ongoing subscription commitment.
Example: AI token credit packs
Small pack:
Code
Large pack (better per-credit rate):
Code
Credit mapping: Credits are arbitrary units. You define how many credits
each API operation consumes via the MonetizationInboundPolicy meter
configuration:
Code
Stripe behavior: One-time payment for the credit pack. Credit balance is tracked internally. Customers can purchase additional packs at any time (top-ups).
Mixing models on one pricing page
You can offer multiple billing models simultaneously. A common pattern:
| Tier | Model | Configuration |
|---|---|---|
| Free | Fixed quota | 1,000 requests/month, hard limit, no credit card required |
| Starter | Fixed quota | 10,000 requests/month, $29/month, hard limit |
| Pro | Quota + overage | 100,000 requests/month, $99/month, $0.001/request overage |
| Enterprise | Pay-as-you-go | Volume-discounted per-request pricing, custom terms |
| Credit Packs | Prepaid credits | Buy 50K/$49, 500K/$299, 5M/$1,999 |
Each is a separate plan in Zuplo. The Developer Portal displays them together on the pricing page, and customers choose the model that fits their usage pattern.
Choosing the right model
| Factor | Fixed Quota | Pay-as-you-go | Quota + Overage | Credits |
|---|---|---|---|---|
| Revenue predictability | High | Low | Medium | Medium |
| Customer budget clarity | High | Low | High | High |
| Barrier to entry | Medium | Low | Medium | Low |
| Revenue upside from heavy users | None | High | High | Medium |
| Payment risk | Low (advance) | High (arrears) | Medium | None (prepaid) |
| Best for | SaaS APIs | Dev tools, AI | Enterprise | AI, marketplaces |