What Throttle stores
The objects Throttle owns, the one thing it deliberately does not store, and how workspace, application, and environment scope everything else.
Most integration surprises come from a wrong mental model of what lives where. This page is the model: what Throttle owns, what it does not, and the three-level scope every record sits inside.
Throttle does not store your products
There is no product catalog. No products table, no variants, no inventory, no images.
Product data arrives from your storefront in the cart payload — name, price, quantity, an identifier of your choosing — and Throttle saves it as line items on the cart and the order. Your catalog stays wherever it already is.
| You keep | Throttle takes over |
|---|---|
| Products, variants, inventory | Carts and line items |
| Merchandising and search | Checkout and payment capture |
| Product content and images | Orders, refunds, returns |
| Category and collection logic | Customers, subscriptions, invoices |
The practical consequence is that anything Throttle does per product — a discount scoped to certain items, for instance — matches on whatever identifier you sent, not on a catalog it can look up.
The three-level scope
Every operational record is scoped by three things, and all three are resolved from your API key before your request runs:
- Workspace — the billing and membership boundary. One company.
- Application — a storefront or product inside it. Orders belong here.
- Environment — production, or one of your sandboxes.
Two applications in the same workspace share a bill and a team but never each other’s orders. Two environments in the same application share nothing operational at all — a customer created in test does not exist in production.
The objects
Cart — a working basket. Line items, totals, an optional customer. Mutable while open.
Checkout session — a cart handed to the payment surface. Carries what to collect (shipping address, billing address) and is what the embed renders against.
Order — the durable record created when checkout completes. Line items are frozen onto it; it no longer depends on the cart.
Payment — money against an order. An order can have several. Carries amount (authorized) and capturedAmount (taken), which are not always the same number.
Fulfillment — goods reaching the buyer. Five types — shipment, digital, access, service, in-person — because “delivered” means different things. An order can be fulfilled in parts.
Customer — the thread tying orders, saved cards, addresses, and subscriptions together. Set externalId to match your own records without storing our UUIDs.
Subscription — a recurring billing relationship reusing the card vaulted at checkout.
Invoice — what a buyer owes, whether from a card capture, a Net-N issuance, or a subscription charge. One list regardless of origin.
Quote — a B2B proposal that converts into an order on acceptance.
Discount — a promotion code. Percentage or fixed amount.
What is shared, and what is not
Not everything is environment-scoped, and assuming it is causes confusion:
| Scope | Examples |
|---|---|
| Per environment | Orders, customers, carts, payments, subscriptions, discounts, API keys, webhooks |
| Per application | Branding, currency, allowed origins, email settings |
| Per workspace | Team members, billing, audit log, the extension catalog |
So an extension published in your workspace is visible in every environment, but the installation and its config are per environment.
Money is always in minor units
Every amount in the API is an integer in the currency’s smallest unit — 2999 is $29.99. There are no decimal amounts anywhere, in requests or responses.
One currency per application. A cart in a different currency is rejected rather than converted, and omitting the currency inherits the application’s.
Last updated August 9, 2026