Zuplo
API Monetization

Turn API traffic into revenue

Stripe-connected subscriptions, plan-scoped API keys, real-time metering, soft and hard quotas, and a self-serve pricing page — everything you need to bill for an API, in one policy on every route.

Start for Free Read the Docs
Monetization Console
STRIPE CONNECTED
MRR$48,312+8.2% MoM
Active subs412across 3 plans
Trialing3814-day default
Overage rev$2,841this period
CustomerPlanUsage this periodOverageMRR
Real-time metering
Stripe subscriptions + invoicing
Soft / hard limits + overage
Why this matters

Billing logic doesn't belong in your API code

Every API team that wants revenue ends up building the same metering, billing, and entitlement plumbing. Multiplied across thousands of teams, that's an enormous waste. The gateway already sees every request — it should be the meter, the entitlement check, and the bridge to Stripe.

×

Stripe + custom usage code = your weekend

You'd love to charge for usage. So you build a metering pipeline, batch jobs, reconciliation against Stripe, a usage dashboard, and a way to surface limits to customers. Three sprints in, you're maintaining a billing system, not shipping the API.

×

Billing leakage eats 10–20% of API revenue

Plan limits live in your docs, not your gateway. Customers blow through quotas, sales has to chase, and the CFO writes off the rest. Every “upgrade conversation” is two weeks of Slack instead of a button click.

×

Metering and access tied to two systems

Stripe knows the subscription. Your gateway knows the request. They drift. A customer downgrades, the gateway forgets, and they get pro features for another month.

×

AI cost passthrough is a math problem

Each LLM call costs a different amount. Your customer sees it as a request. You see it as $0.04. Multiply by a thousand customers and the gross-margin spreadsheet looks worse every quarter.

What you get

A complete monetization stack, built into the gateway

Stripe-connected from day one

Subscriptions, invoicing, payments, plan changes, proration, cancellation — all flow through Stripe. Zuplo handles entitlement and metering at the edge; Stripe handles the money. Both speak to each other automatically.

Real-time metering, not batch jobs

Every request increments your meters in real time at the edge. No nightly reconciliation, no "why is the invoice off," no 14-day delay between usage and bill. The gateway is the meter.

Self-serve pricing page included

Drop zuploMonetizationPlugin into your developer portal and a Pricing page, Subscription Management, and Usage Dashboard appear. Customers subscribe, upgrade, and watch their quota — your team stays in product.

Plans, meters, rate cards

Compose any pricing model from the same primitives

Meters count things. Features connect meters to your product catalog. Plans bundle features into rate cards with prices and entitlements. Free tiers, pay-as-you-go, quotas with overages, credits, multi-currency — all the same building blocks.

JSONMonetizationInboundPolicy · per route
{
  "name": "monetize-route",
  "policyType": "monetization-inbound",
  "handler": {
    "export": "MonetizationInboundPolicy",
    "module": "$import(@zuplo/runtime)",
    "options": {
      "cacheTtlSeconds": 60,
      "meters": {
        "api_requests": 1
      }
    }
  }
}
TypeScriptMulti-meter charge from your handler
import {
  MonetizationInboundPolicy,
} from "@zuplo/runtime";

// Inside an LLM route handler
const tokens = countTokens(prompt) + countTokens(completion);
MonetizationInboundPolicy.setMeters(context, {
  api_requests: 1,
  tokens, // billed at rate-card rate
});
Stripe-connected billing
Plan-scoped API keys
Real-time meters · 7 aggregations
Soft/hard limit per feature
Self-serve pricing + checkout
Multi-currency · multi-cadence
Read the Quickstart Stripe integration docs
What makes Zuplo different

Monetization that feels like a feature, not a project

First-party, not a passthrough

MonetizationInboundPolicy isn't just a Stripe SDK wrapper. It's a meter, a quota engine, an entitlement check, and an API key gate — all running in the same edge runtime as the rest of your gateway, with Stripe as the billing system of record.

Bill on any unit that costs you

Requests, tokens, GB transferred, compute credits, rows returned, AI calls, custom metrics from your backend — each maps to its own meter and rate card. One request can charge multiple counters. Cost passthrough for AI and data workloads stops being a spreadsheet exercise.

Plan-scoped API keys

Subscribing generates an API key tied to the plan. Plan changes update entitlements without rolling the key. Cancellation revokes the key at period end, after Stripe finishes billing. One key per customer, the whole lifetime.

Soft + hard limits, configured per feature

Hard limit on the trial tier: 429 at the cap. Soft limit on the paid tier: bill the overage at the rate-card rate. Trial users feel a wall; paid users feel an invoice. Both behaviors live in the same plan config.

Real questions, real answers

What teams use this for

“Free tier with 1k calls, paid tier with 5k calls + overage.”

Set up two plans — a free Developer tier capped at 1k calls per month, and a $9.99/mo Pro tier with 5k calls included and per-call overage. Customers subscribe through your developer portal, Stripe handles checkout, and Zuplo issues a plan-scoped API key. Live in an afternoon.

“Charge customers for the AI tokens our backend actually used.”

Your backend returns the real token count in a response header (e.g. x-tokens-used: 1834). The gateway reads it, charges the customer for that exact amount on the tokens meter, and strips the header before the response goes out. No client-side math, no double-counting, no separate billing service.

“Support needs to suspend a customer or move them to a different plan.”

From the admin UI or the Monetization API: suspend a consumer instantly (every request returns 403), migrate them between plans (entitlements update without rolling the key), or override a single customer's quota for one cycle. Customer ops doesn't need an engineering ticket.

“API access has to follow our existing subscription system, not Stripe.”

Write a small custom policy that checks your subscription system (MemberStack, Salesforce, your own DB) before each request and denies access when the parent subscription lapses. Zuplo still meters and rate-limits — but entitlement is gated by the system you already bill from.

Frequently Asked Questions

Common questions about API monetization with Zuplo.

Stop building billing plumbing. Ship pricing instead.

Free Zuplo project, Stripe-connected subscriptions, and a self-serve developer portal — bill for your API in an afternoon.

Get a Pricing Demo Start for Free