The 5-second value
- Authorize before cost: call Unprice in the request path before the paid action creates margin damage.
- Keep pricing out of app branches: plans, plan versions, features, meters, entitlements, budgets, and wallet credits stay connected but separate.
- Explain after billing: accepted usage carries evidence from the decision that allowed it to the invoice line that bills it.
Start with one paid action
Pick the action that can burn a customer’s credits, budget, or usage allowance: an LLM call, API request, data job, workflow, export, or tool run.1. Model the rule
Publish one plan version and map one customer to it.
2. Choose the runtime call
Pick
access.check, usage.consume, usage.record, or runs.3. Inspect the evidence
Follow wallet credits, holds, usage, and invoice evidence.
The runtime calls
| If your app needs to… | Call | What it means |
|---|---|---|
| Ask “is this customer commercially allowed?” without changing state | access.check | Read-only preflight, safe for shadow mode |
| Enforce a known usage amount in the request path | usage.consume | Synchronous decision; deny when the limit or funds are exhausted |
| Report usage for metering and invoice evidence without blocking | usage.record | Asynchronous ingestion; never a spend gate |
| Reserve a budget before a multi-step workload runs | runs.start / runs.consume / runs.end | Budget envelope for a job, workflow, tool, agent, or custom run |
Why not just a counter?
A counter can say usage is high. It cannot reliably prove which plan version applied, which credits were reserved, why a request was denied, or how accepted usage became an invoice line. Unprice keeps the customer spend decision and the invoice explanation on the same inspectable path.Quickstart
Put one paid action on the money path.
TypeScript SDK
Install the SDK and call the public API with typed results.