01
Meter every billable event
Capture API calls, credits, seats, storage, jobs, or any product action with consistent customer and feature context.
event.accepted
Usage metering + billing
Track usage, enforce limits, and bill from one reliable source of truth.
01 Event
02 Count
03 Limit
04 Bill
$48,320
Tracked MRR
event_received
api_request
POST /v1/render
12.4M
Metered events
99.99%
Captured
48MS
P95 check
One source of truth
The same event moves through metering, access control, pricing, and billing. There is less to reconcile because the system never loses the thread.
01
Capture API calls, credits, seats, storage, jobs, or any product action with consistent customer and feature context.
event.accepted
02
Evaluate entitlements and quotas in real time so expensive actions only happen when a customer has access.
access_granted
03
Connect plans, metered features, credit balances, and overages to the same source of truth.
limit 10,000
04
Issue invoices and receipts from verified usage, then reconcile provider activity without spreadsheet drift.
invoice.ready
Operational clarity
Usage events, plan limits, customer state, invoices, and provider activity stay connected from the first request to the final receipt.
The interface is intentionally quiet: blue means live or actionable; neutral surfaces hold context; hairlines show structure without turning every object into a card.
Production workspace
Usage and revenue overview
Metered events
12.4M
+18.2% this period
Tracked MRR
$48,320
184 active subscriptions
Capture rate
99.99%
Across production events
Current period
API requests
78.42%
Result
Access granted
Overage
Not triggered
Event stream
api_request
cus_9f2a
+1
accepted
credit_spend
cus_b41c
-12
accepted
plan_limit
cus_1d87
78%
allowed
invoice_threshold
cus_9f2a
$129
ready
Precision flow
Start small with a single billable event, then add plans, limits, credits, and billing without replacing the foundation.
01
Model plans, features, quotas, credits, and overage rules in a sandbox workspace.
plan.model ready
02
Ask Usagey whether a customer can perform the action before costly work begins.
access allowed
03
Record the successful billable event with an idempotency key and useful metadata.
event +1 captured
04
Turn trusted usage into limits, overages, invoices, receipts, and revenue reporting.
invoice item ready
Developer first
Check access before the work begins. Track the event after it succeeds. Usagey keeps the operational detail visible without leaking billing complexity into your product.
import { Usagey } from "@usagey/sdk";const usagey = new Usagey(process.env.USAGEY_API_KEY!);const access = await usagey.check({ externalId: "customer-42", feature: "api_requests",});if (access.status !== "access_granted") return access;// Run the billable work, then record successful usage.await performBillableAction();await usagey.track( { externalId: "customer-42", feature: "api_requests", quantity: 1, }, { idempotencyKey: "request_01JEXAMPLE" });Public endpoint
POST /v1/usage/check
Public endpoint
POST /v1/usage/track
From the wider conversation
The model feels fair. The hard part is making every event, limit, and invoice trustworthy.
A great developer tool!
Worth a look if you're exploring this pricing model.
The infrastructure complexity is spot on. Reliable metering can become a massive distraction from core product development.
The hard part is the backend: tracking usage accurately, turning it into billable units, and making sure invoices match what customers see. If that breaks, trust breaks.
Usage-based pricing works really well when you tie it to a metric customers instantly understand, like compute time, messages, or transactions.
The tricky part isn't the pricing logic. It's tracking and billing it correctly.
Pricing
Choose the stage that matches your product today, then move up when usage becomes real revenue infrastructure.
Need more event volume, custom workflows, or help migrating from a DIY billing stack?
Frequently Asked Questions
The practical details founders ask before trusting usage data with billing decisions
Ready when usage becomes revenue