Everything you sell sits in the Catalog. A product is the thing a customer subscribes to — your Translation API, your Vision agent, your MCP search server. A billable unit is the meter you read off that product — calls, tokens, sessions, gigabytes. Get the catalog right and every page after it (rate plans, invoices, analytics) lines up. Get it wrong and you re-do work later.
Catalog is the operator-facing inventory of products and meters. It is NOT pricing (that's Pricing Studio), NOT customers (that's Storefront → Customers), and NOT the storefront page they buy from (that's Storefront → Customize). Think of it as the menu — you list dishes here; you price them, plate them, and serve them elsewhere.
INFO
Catalog data is the load-bearing object for every other section. Rate cards reference billable units, offerings bundle rate cards, invoices summarize products, and analytics rolls everything up by product. Most "the dashboard shows zero" tickets trace back to a billable unit that was never created or a product that was never associated.
ProductA buyable unit of value. Maps 1:1 to something your customer would put on a contract — "Translation API v2", "GPT-4 Agent", "S3-compatible storage".5–30 in a typical workspace
Billable UnitA meter — the count you charge against. Per product type Aforo seeds industry-standard units (request counts, tokens, tool calls, session duration, and so on) and you add custom ones.2–10 attached per product; 5–9 default units per product type before you customise
The many-to-many that catches people out
A billable unit is NOT owned by a product. The same api_calls unit can be attached to your Translation API AND your Vision API; the same tokens_out unit can attach to every AI agent you sell. The association is a junction (product_metrics) — change a unit's definition once and every product using it picks it up.
Say you sell a Translation API. The catalog entries are:
EntityNameWhy it's defined this way
ProductTranslation API v2One product — customers contract for "Translation API", not for the api_calls meter on its own.
Billable Unitapi_callsCOUNT aggregation. Tracks request volume — the main pricing dimension.
Billable Unitcharacters_translatedSUM aggregation. Tracks the actual work done — useful for an overage tier.
Billable Unitp95_latency_msP95 aggregation. Not billed (rate = $0); kept for SLA reporting in Analytics.
With that catalog in place you can move to and build a rate card that charges $0.05 per api_call with a 10k-call included quota, plus a $0.0001-per-character overage on characters_translated.
Aforo ships with four generally available product types (four more — GraphQL, gRPC, WebSocket, MQTT — are marked Coming Soon). Picking a type auto-seeds the default billable units for that shape:
API
REST / HTTP endpoints. Default units: API Calls, Data Transfer, Active Users, Compute Time, Error Requests.
Once your products and billable units exist, every downstream section reads from them:
Pricing Studio — rate cards charge against billable units; offerings bundle rate cards per product.
Gateways & SDKs — every metered event references a billable unit name; the ingestor rejects names that don't exist in your catalog.
Intelligence — dashboards group revenue by product; usage drill-downs filter by billable unit.
Storefront — the public product card displays each product's name + description + feature list.
PRO TIP
If you're starting fresh, build catalog before pricing. The wizard makes you pick a product type and pre-seeds the standard billable units for that shape — you almost always want those defaults rather than starting from a blank slate.