Skip to main content
When creating or viewing subscription items, each item has a price object containing a type field that determines which pricing model is used. Exactly one pricing model field will be populated, matching the type.

Supported Pricing Types

Common Fields

Every price includes these fields alongside the model-specific field:
When creating prices, currency is inherited from the subscription and should not be specified. In responses, currency is always included.

Pricing Model Examples

Unit Pricing

Simple per-unit rate. Best for metered products where each unit costs the same.

Fixed Pricing

Flat amount for a fixed quantity of units. total is computed server-side (not required in requests).
In responses, the total field is included:

Tiered Pricing

Total usage determines which tier applies. All units are priced at that single tier’s rate.

Graduated Tiered Pricing

Each tier is priced independently. Units 0-1000 at 0.20,units100110000at0.20, units 1001-10000 at 0.15, etc.

Tiered Percentage Pricing

Percentage-based tiers. Total usage determines which tier’s percentage applies to all units.

Graduated Percentage Pricing

Each tier’s percentage applies independently to the units within that tier.

Volume Percentage Pricing

Charges a percentage of transaction volume plus an optional fixed fee per transaction.

Prepaid Tiered Pricing

Customer pre-purchases a block of units. Overages are charged at tiered rates.

Prepaid Fixed Tiered Pricing

Like prepaid tiered, but with a configurable overage charge interval.

Expression Pricing

Custom expression-based pricing. Each charge is a pair of formulas — one for the quantity, one for the unit price — evaluated with decimal precision. Referencing metrics. An expression references a bound metric directly by its metric ID (e.g. met_compute_hours) — metric IDs are valid expression identifiers, so no separate name is needed to use one in a formula. metric_bindings optionally gives a metric a short alias purely for display in the pricing editor UI; the alias itself is never a legal expression variable and never appears in a stored or evaluated expression. Every bound metric must also appear in metric_ids.
Available variables usage and event_count are back-compat variables for a price with no bindings. As soon as you bind any metric via metric_bindings, they leave scope — address each metric’s value through its <metric_id> and its event count through <metric_id>_count. metric_bindings[].alias is a display-only name for the pricing editor UI — it must be a valid identifier, must not collide with usage/event_count, and must not end in _count (so the editor can unambiguously tell an alias like requests_count apart from the auto-derived _count display name it generates for a different alias, e.g. requests). None of this alias hygiene affects evaluation: an alias is never itself a legal expression variable, at save time or at charge time. Operators & functions: arithmetic (+ - * /), comparisons (> >= < <= ==), ternary conditionals (condition ? a : b), and min / max / abs.
Every variable resolves over the current billing period. Longer-horizon aggregates (contract-to-date, all-time) and contract lifecycle values (term, days remaining, …) are intentionally excluded — those are re-pricing conditions handled by escalation/re-pricing automations, not inputs to a charge formula.

Discounts

Price-level discounts support both percentage and fixed types:
Subscription-level discounts (set via PATCH) only support percentage type. Price-level discounts support both types.

Spending Thresholds

Both minimum_spend and maximum_spend use the same structure:

Tier Structure

Standard Tiers (unit-based pricing models)

Used by tiered, graduated_tiered, prepaid_tiered, and prepaid_fixed_tiered models:

Percentage Tiers

Used by tiered_percentage and graduated_percentage models: