AI & API monetization

Measure the usage first. Change the pricing later.

Requests, tokens, tasks, tool calls and outcomes are product facts. Credits, markup, packages and invoices are pricing decisions. Keep those layers separate so monetization can evolve without re-instrumenting the API.

Preview a real requestStart freeModel pricing & margin
What you get
  • One durable quantity layer under subscriptions, credits or usage pricing
  • Idempotent events for retries and queue redelivery
  • Raw evidence for customer disputes and reconciliation
  • Pricing and credit policy stay outside the meter

Meter what the product actually did

Count the stable quantity your system can defend: requests, tokens, tasks, tool calls, active users or another numeric unit. That quantity should survive pricing changes.

Price in a different layer

Pass-through, markup, flat packages, included allowances and prepaid credits are rating decisions. Apply them in your billing or application layer instead of baking them into instrumentation.

Keep gateway quotas separate

Rate limits protect the hot path. Billing meters preserve history. A gateway counter can block traffic without becoming the financial source of truth.

Support marketplace and direct customers

If some buyers arrive through a marketplace and others contract directly, keep one independent usage record behind both channels so totals can be reconciled consistently.

Change packaging without changing producers

Move from per-request to hybrid pricing, or from credits to committed usage, without editing every call site. The application keeps emitting the same measured fact.

Explain the invoice later

Retained accepted events and rollups let support trace a billed quantity back to the usage that produced it instead of relying on an ephemeral quota counter.

Implementation pattern

One measured request; pricing stays downstream

The application records the quantity. Your billing system decides whether that quantity becomes a credit drawdown, a marked-up line item, an included allowance or an overage charge.

For richer model/task/evaluation metadata, keep that telemetry in your application analytics or split distinct billable streams into explicit meters/product items. The public usage payload remains intentionally small.

curl -X POST https://api.usagebox.com/api/v1/usage \
  -H 'x-api-key: <your_api_key>' \
  -H "Idempotency-Key: $(uuidgen)" \
  -H 'Content-Type: application/json' \
  -d '[{ "subscription": "<subscription_ingest_key>", "meter": "<meter_ingest_key>", "value": 1 }]'

Product boundary

UsageBox is the quantity ledger, not the pricing engine

That boundary is what keeps monetization flexible. The measured fact should be stable; customer-facing pricing and financial operations can evolve independently.

UsageBox owns

  • Usage event ingest
  • Idempotency
  • Raw accepted history
  • Meter aggregation
  • Monthly quantity rollups

Your stack owns

  • Authentication and rate limits
  • Credit balances and expiry
  • Price/markup rules
  • Invoices and tax
  • Payments and collections

See the request before you create an account

Choose the usage signal, inspect the exact payload, then create a free key only when the contract fits your integration.

Preview a real requestStart freeSee pricing