Price Lists
Usage & Overview
Octane lets you charge your customers for metered usage by creating Metered Components. A metered component is specified on a Price Plan and is a pricing scheme attached to a meter (as seen in the picture below). "Price Lists" extend this paradigm by allowing you to charge on the specific primary labels attached to the given meter. Price Lists are defined by uploading a CSV, allowing for custom pricing on many combinations of labels and their values. Price Lists can be specified in JSON format and uploaded directly to the API. Here's a link to our API documentation on creating a price plan.
Creating a Price List

Let's say we run a car rental company, and assume we wanted to price based on hours driven in each car. Our cars have labels for two distinct qualities: the type of car and the type of roof. Here is an example pricing structure we might use:
Price | Car Type | Roof Type |
---|---|---|
$9 | Bugatti | Convertible |
$5 | BMW | Regular |
In our portal the above table corresponds to the below CSV that you would upload when creating a price plan:
car_type, roof_type, prices
bugatti, convertible, price=900
bmw,regular, price=500
The meter in question here, “Car Meter” has two primary labels “CAR_TYPE” and “ROOF_TYPE”. For the metered usage attached to Bugatti Convertibles (i.e., “CAR_TYPE”: “Bugatti” and “ROOF_TYPE”: “Convertible”) we charge $9, whereas for BMWs with Roofs (i.e., “CAR_TYPE”: “BMW” and “ROOF_TYPE”: “Regular”) we charge $5. These flat $9 and $5 quantities are examples of “flat” pricing. (Note the csv values are in cents, not dollars)
Supported Schemes
The CSV upload process also supports more complex pricing schemes than FLAT. We support TIERED, STAIRSTEP, & VOLUME. They are largely documented here: https://docs.getoctane.io/docs/pricing-scheme-types. In order to express these cap-based price schemes you must, instead of the single price above, insert a json list of prices with caps. Borrowing the pricing from this link https://docs.getoctane.io/docs/pricing-scheme-types, let’s say that usage is attached to a meter with the primary label “car_type”
In this example, for usage of the car type BMW and roof type regular, there is a tiered price scheme: for 0-100 measurements, the price is .80 per measurement; for 101-200 measurements, the price is .60 per measurement". Beyond that it is .30 per measurement.
The way we would translate the above car-type-pricing to a price list, pricing on “car_type” is below. For other car_type’s other than post we charge 0$ (as discussed below in the miscellaneous section)
Car Type | Roof Type | Prices |
---|---|---|
Bugatti | Convertible | [{"price": .50, "cap": 100}, {"price": .40, "cap": 200}, {"price": .30}] |
BMW | Regular | [{"price": .80, "cap": 100}, {"price": .60, "cap": 200}, {"price": .40}] |
The CSV format of the above - to be uploaded in our customer portal - of the above table:
car_type, roof_type, prices
bugatti, convertible, [{"price": .5, "cap": 100}, {"price": .40, “cap”: 200}, {"price": .30}]
bmw, regular, [{"price": .80, "cap": 100}, {"price": .60, "cap": 200}, {"price": .40}]
In all the cap-based pricing schemes (i.e., volume, stairstep, & tiered) it’s important to note that the order of the (price, cap) tuples defines the ordering of the buckets.
Miscellaneous Notes
- When creating price lists ensure that the labels you are specifying in the upload process are a strict subset of the primary labels on the metered component. The upload will error out otherwise
- A price must be set in each row & must be nonnegative
- We currently support uploading a maximum of 1000 rows in a given price list
- Uncategorized usage will be billed as $0 on invoices.
- The price lists upload process only accepts ascii quotes, so unicode quotation marks (like Apple’s default quotes in sticky notes, for example), will result in an error upon upload
Updated 8 months ago