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.

Matrix Pricing

Routes each usage event to a priced cell based on its property values, so a rate can vary along more than one dimension at once. Each cell carries its own pricing model, so one branch can be a flat per-unit rate while another is tiered. A matrix has two parts:
  • dimensions — the event property keys the matrix routes on, with display labels. values lists the values you author in the UI; it does not restrict what the matrix can match at charge time.
  • root — a routing tree. Each node either holds a leaf (the priced cell) or splits (ordered routing choices). A split names a dimension_key and lists exact-value branches; wildcard catches a value that is present but has no exact branch, and fallback catches an event that no split claims at all.
An event carrying region: "eu" is charged at 0.25 per unit. An event carrying any other region value falls to the wildcard and is charged on the tiered schedule. An event with no region property at all is charged by the fallback cell at 0.30. Cell pricing models. A cell’s type may be unit, fixed, tiered, graduated_tiered, tiered_percentage, graduated_percentage or volume_percentage, with the matching *_pricing_model object. expression, matrix and the prepaid types cannot be used inside a cell. line_item_template sets the default invoice line description for cells, interpolating dimension keys in single braces (for example {product} / {region}). A cell’s own label overrides it, including an explicitly empty label.
Omit cell_key when creating a matrix. It is the stable identity of an existing cell, returned in responses, and is used to preserve a cell’s identity when you update the matrix later.

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: