Usage-based billing on events

Ingest events. Aggregate them into meters. Bill on the result.

Send events from your application. Polar aggregates them into meters and writes line items on the next invoice.

Events, meters, prices

The model is built on three primitives that compose. It starts with events, immutable records of something that happened in your product, posted with a customer ID and any metadata you want to keep.

On top of those events sit meters, which filter and aggregate the stream into a number per customer. Pick how the number is calculated (count, sum, average, min, max, or unique) and the rest is bookkeeping.

A meter only matters once it's priced, which is what metered prices are for. Attach one to a product and Polar reads the meter at the end of each cycle, then adds the corresponding line item to the next invoice.

The whole pipeline reuses the rest of the system. Renewals, proration, tax, and discounts behave the same way they do for fixed-price products, so usage billing slots in next to whatever you're already selling.

Event ingestion

Post events from your application or use SDK strategies for LLMs, streams, and S3.

Customer meters

Per-customer meters that update in real time as events arrive.

Metered prices

Attach a meter to a product. Polar bills the consumed amount on the next invoice.

Customer state

A single API call returns every active meter and current balance.

Six aggregation functions

The same event stream can power multiple meters. Change pricing without re-instrumenting your application.

  • CountTotal number of events that match the filter. For API calls or per-action billing.
  • SumAdd a metadata property, like total tokens, bytes processed, or seconds of compute.
  • Min, max, averageDerived metrics like peak concurrency or average response size.
  • UniqueCount distinct values of a property. Charge per unique user, project, or document.

Ingestion strategies

The Polar SDK ships helpers for the most common event sources. Wrap a model client, an S3 bucket, or any HTTP body and the events flow.

  • LLM strategyWrap an OpenAI-compatible model. Polar counts prompt and completion tokens automatically. Works with the Vercel AI SDK and any model that returns a usage block.
  • Stream strategyTap a streaming response and count chunks, bytes, or duration. For transcription, generation, or any long-lived call.
  • S3 strategyMeter file uploads and downloads through your S3-compatible storage. Bill on bytes transferred or objects created.
  • Delta-time strategyMeasure wall-clock time spent inside a function or session. Bill per second of usage.
  • Manual ingestionWhen the strategies don't fit, post events directly through the SDK.

Customer meters

Every metered customer carries a live customer meter that updates as events arrive, readable from the API or shown directly in the Customer Portal. Your dashboards and your customers' in-app views can read from the same source without you keeping a parallel ledger.

One thing Polar deliberately does not do is block usage when a customer crosses a quota. That decision belongs in your product, where you know the context. The meter exposes the signal, and you choose what to do with it: enforce a hard limit, prompt for an upgrade, or let the overage flow through to the next invoice.

Start metering events

Set up a meter and ingest your first event with the SDK.