Skip to main content
Prices define how much you charge for each billable metric within a plan.

​
Pricing models

​
Standard pricing

Fixed cost per unit. Simple and predictable — and the only model you create. Standard covers flat per-unit rates, percentage-style multipliers, and revenue share. Every unit costs the same amount regardless of volume. If you charge $0.001 per token, the 1st token costs the same as the 1,000,000th token. Use cases:
  • Flat rate per token
  • Fixed cost per GB
  • Standard hourly rates
  • Per-seat licensing
  • Percentage / revenue share (see below)

​
Percentage and revenue share (standard multiplier)

To charge a percentage of a value, use a standard price whose unit price is the rate. The monetary value flows in as the metered quantity, so quantity × unitPrice produces the percentage charge — no separate “percentage” model needed. Example: To take 10% of transaction value, create a standard price with unitPrice: "0.1". A $100 transaction bills $10 (100 × 0.1). For a 2.9% processing fee, use unitPrice: "0.029"; for 1% revenue share, unitPrice: "0.01". Use cases:
  • Revenue sharing
  • Transaction / processing fees
  • Commission models
  • Marketplace takes
A standard multiplier is uncapped — there is no per-transaction minimum or maximum charge. If you need caps, apply them in your usage pipeline before sending the metered value.

​
Usage-scaled rebates (negative unit price)

A standard price with a negative unit price is a rebate that scales with measured usage. It generates an ordinary metered line whose subtotal is negative, so it reduces the invoice rather than adding to it — and it recurs every billing period like any other price, inheriting plan versioning, per-subscription overrides, cadence and payment term. Example: A price with unitPrice: "-0.50" against a usage metric rebates $0.50 for every measured unit. At 300 units the line is -$150.00. Rebate threshold. Attach a metered feature whose entitlement template sets isSoftLimit: true, and the rebate applies only to usage above the entitlement’s allowance — “no rebate on the first N units”. A soft-limit feature is required to combine a rebate with a feature.
A rebate can reduce a bill to $0.00 but never below it. Configure rebate rates so the rebate stays below the charges it offsets over a billing period; if a rebate would exceed an invoice’s charges, the invoice is held for review rather than issued. Lower the rebate rate — or raise the charges it offsets — and the held invoice can be recalculated and issued. A held invoice is never issued on stale totals: it either recalculates cleanly or stays held.A rebate is folded into the charge lines on the tax document, so it is not shown as a separate line — the customer sees reduced effective unit prices that reconcile to the same total.
A negative unit price cannot be combined with grant discounts (grantDiscountEnabled), a hard-limit feature, or a credit-denominated price (pricingUnitId); the API rejects these.Feature basis. Several prices may bill the same measured usage, each at its own rate — a rate plus a percentage, a rate plus a rebate, and so on. When a rebate price and a charge price share the same billable metric but attach to different features (one billing overage above an allowance, the other billing raw usage), they compute against different quantity bases. That is a valid configuration — a bundled allowance alongside a passthrough charge — but it is worth double-checking it is the one you intended.

​
Legacy models (read-only)

dynamic, volume, and percentage are legacy models. Prices that already use them keep billing exactly as before, but new prices can no longer be created with them and existing prices can’t be switched to them. Use standard instead — the API rejects these models on create/update, and the platform UI no longer offers them. The old percentage model’s min/max caps have no standard equivalent (see the note above).

​
Payment terms

Control when and how customers are charged for usage.

​
In advance

Charge at the start of each billing period before usage occurs. The customer is billed upfront for the upcoming period. Perfect for:
  • Recurring subscription fees
  • Platform access charges
  • Per-seat licensing
  • Any fixed fee on Standard Billing plans

​
In arrears

Accumulate charges throughout a billing period and bill at period end. Customers pay after usage has occurred. Perfect for:
  • Metered usage (tokens, API calls, storage)
  • Enterprise contracts with NET payment terms
  • Large transaction volumes
  • Traditional invoicing workflows

​
Instant (withdrawn)

instant charged in real time as each usage event occurred. It is no longer available. Use in_advance or in_arrears instead.
paymentTerm accepts in_advance and in_arrears. No plan accepts instant, on either billing model. See Billing Versions for payment term constraints by billing model.

​
Linking a feature

A price can automatically provision an entitlement when a customer subscribes by linking it to an entitlementTemplate. This is how you grant access to features — quota limits, reset periods, and rollover behavior — directly through the plan’s pricing. To grant a feature without charging for it, set unitPrice: "0" on the price and attach the entitlementTemplate. When a customer subscribes to the plan, the entitlement is provisioned automatically. Key points:
  • The entitlementTemplate on the price defines the grant: quota amount, reset cadence, and rollover behavior
  • Requires Standard Billing (billingVersion: 1)
  • A single price can carry at most one entitlement template
See Features and Entitlements for the full configuration reference.

​
Combining models

Mix different approaches within one plan to optimize for your business. Example: AI Platform
  • Base platform access: $499/month (standard, in advance)
  • Token usage: $0.002/token (standard, in arrears)
  • Enterprise support: $5000/month (standard, in advance)
Example: Data Warehouse
  • Storage: $0.02/GB-month (standard, in arrears)
  • Queries: $0.75/query (standard, in arrears)
  • Data export: 1% of monthly bill (standard multiplier, unitPrice: "0.01", in arrears)

​
Design principles

Start simple. Standard pricing covers 90% of use cases. Add complexity only when needed. Match customer expectations. B2C favors charging in advance, B2B prefers invoicing in arrears.

​
Next steps