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

fee_type is set independently of type: a unit price can be fixed or metered. Set it to match how the charge behaves, and supply metric_ids whenever it is metered.

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. mtr_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: