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).
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.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.
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.valueslists 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 aleaf(the priced cell) orsplits(ordered routing choices). A split names adimension_keyand lists exact-valuebranches;wildcardcatches a value that is present but has no exact branch, andfallbackcatches an event that no split claims at all.
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 bothpercentage and fixed types:
Subscription-level discounts (set via PATCH) only support
percentage type. Price-level discounts support both types.Spending Thresholds
Bothminimum_spend and maximum_spend use the same structure:
Tier Structure
Standard Tiers (unit-based pricing models)
Used bytiered, graduated_tiered, prepaid_tiered, and prepaid_fixed_tiered models:
Percentage Tiers
Used bytiered_percentage and graduated_percentage models: