Item types
Keys, top-ups and services — pricing, rate math and Python recipes for each type
Every catalog item carries a product_type — key, topup, or service —
that determines how the item is priced, what your POST /v1/orders request must
contain, and what fulfillment delivers. This page is the deep dive on each type.
The records themselves come from your catalog snapshot; the
request/response mechanics live in Placing orders.
Pricing fields (all types)
Catalog prices are integers in cents — divide by 100 for major units. Every record carries three of them:
The charge for an order is quantity × price (in cents). The order response
confirms the actual amount charged in its price field, already converted to
major units — e.g. a catalog price of 2400 and quantity: 2 comes back
as "price": 48.00.
Estimates are for display and pre-checks only. The final charge is always
the price on the order response — the catalog is a snapshot and prices can
change between downloads.
Key items
A key item is a stock of pre-generated codes: gift cards, license keys,
vouchers. You buy whole codes, so quantity is an integer count of how
many codes you want (default 1), bounded by the record’s
min_quantity/max_quantity. Key items take no fields.
- Charge —
quantity × pricecents. - Delivery — the order settles
completedwith the code strings incodes, anddelivered_quantitytells you how many were delivered. - Partial delivery — if stock runs out mid-order, the order settles
partial:codesholds what was delivered andrefund_amountcovers the missing units. Always reconciledelivered_quantityagainst what you asked for, not just the status.
The codes are pushed to your webhook when the order settles —
no polling loop needed. Your handler is where you store the delivered codes and
reconcile a partial delivery:
Polling GET /v1/orders/{id} remains a fallback for missed deliveries — see
Webhook vs polling.
Top-up items
A topup item credits balance or in-game currency to an account your customer
names in fields (a Steam login, a player id, …). Unlike keys, you are not
buying discrete units of stock — you are buying an amount, so quantity is
a decimal and is required.
How price and amount_per_price work together
A top-up record sells in units of quantity, and two fields define what one
unit of quantity means:
price— what one unit ofquantitycosts you, in cents.amount_per_price— what one unit ofquantitydelivers to the customer, in the target currency (USD of Steam balance, UC, diamonds, …).
So for any order:
Calculating the rate
The rate — how much target currency $1 buys — is the ratio of the two
fields. Because price is in cents, multiply by 100 to express it per dollar:
Worked example — a game-currency top-up record with price: 100 (i.e. $1.00
per unit of quantity) and amount_per_price: 110:
If your account has an active subscription you are charged
subscriber_price instead, which improves the rate:
(amount_per_price / subscriber_price) × 100.
Order a target amount end to end
Putting it together: the customer wants a specific amount topped up, you derive
quantity from the catalog record and place the order:
Find the best rate in your catalog
Because the whole catalog is a local LMDB file, comparing rates across every top-up is a plain loop — no API calls:
Service items
A service item is fulfilled manually or by an operator against the account
you name in fields — direct top-ups, boosts, activations. There is nothing to
count, so omit quantity (it is always 1) and the charge is simply the
record’s price.
- Charge —
pricecents, once. - Delivery — the order settles
completedwhen the service is done, orfailedwith a full refund.fieldsis required and describes the target (user ids, regions, package choices, …). - Choice fields — services often use
choicefields (e.g. a package or server picker). Send the selected option’s numericid, not its label.
In order responses, submitted choice fields are echoed back as their human-readable label even though you sent the numeric id — that’s display-only. Keep sending numeric ids on create.