What point in time means
A point in time product is charged based on discrete consumption events, not on access held over a stretch of time. The customer pays when something happens, an API call, an SMS sent, a report generated, rather than on a recurring calendar schedule that exists independent of usage.A quick heuristic: Read the unit phrasing
Before reaching for the formal definition, the way a price is naturally phrased is usually enough to tell whether a product belongs here. Point in time prices carry no time denomination.
This heuristic is not a formal test, since awkward phrasing can undermine it. When phrasing is ambiguous, use the underlying question instead: is the customer paying for access over time, or for consumption at a moment? Prices that carry a time denomination, such as “$X per unit per month,” point to period of time instead; see Product type: Period of time for that side of the heuristic.
Quantity source: Fixed or metered
Quantity source determines how the system knows the number of units:Fixed
The quantity is known upfront and specified directly, for example a customer buying 500 API calls upfront. No usage tracking is needed.
Metered
The quantity is unknown until consumption happens and is tracked from usage events through an aggregate. The system counts; it does not take a declared value at face value.
Quantity type: On demand or recurring
Independent of whether quantity is fixed or metered, a point in time product also carries an on demand or recurring choice. The distinction concerns activation, not invoicing:On demand
The product remains inactive until a triggering event occurs (a customer action, a usage event, or similar). Once triggered, the system bills the resulting charge through the contract’s normal invoicing, typically as a line item alongside other charges.
Recurring
The product activates as soon as the contract goes live and is billed on the contract’s regular cadence from that point forward.
Why pricing period does not apply
Pricing period is the time duration a price is expressed in, the “month” in “$20 per seat per month.” Point in time products have none, because the price is per event, not per time. Asking “what is the monthly price” of a per-call API product is not a well-formed question. The answer depends entirely on usage: 10,000 calls in January might cost $10, and zero calls in March costs nothing. No monthly rate exists to quote, only a per-event rate.Tier reset period: Only matters once pricing stops being linear
For a flat per-unit price, every event stands alone: $0.001 per call regardless of how many calls preceded it. The tier reset period is irrelevant here. It becomes essential the moment pricing turns tiered or volume-based, because the rate then depends on a cumulative total, and something must define when that cumulative counter resets. See tiered: tier reset period and volume: how accumulation differs by product type for how this plays out in each pricing model. A longer tier reset period, quarterly or annual, lets usage accumulate further before tiers reset. This typically gets the customer to better rates sooner but also makes each individual invoice period less predictable in isolation. The reset period is not fully independent, though: it has to tile evenly with both the recurring quantity cadence and the billing cadence, one has to be a whole multiple of the other in each case. A monthly reset on quarterly billing is valid because three months make a quarter; an arbitrary, non-dividing combination is rejected.Fixed vs. metered changes what is required, not just how usage is counted
Quantity and Credits: the two subtypes of a point in time product
Everything above applies to a point in time product regardless of which of its two subtypes it uses:- Quantity: a count of discrete items, such as 5 report generations or 100 API calls. The running example throughout this page.
- Credits: a pool of credits or custom currency units, such as $100 in platform credits, available through the API. The dashboard’s product subtype selector currently disables it.