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