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