Creating a Catalog
Define products using declarative YAML manifests
Before thinking about pricing, you need to clearly define what you're selling. This means identifying the features that differentiate your tiers and structuring your catalog accordingly.
MoneyMQ catalogs are defined using declarative YAML files, enabling version control, code review, and GitOps workflows. This keeps your revenue model in sync with your codebase — and works seamlessly with coding agents.
Directory Structure
Products follow a hierarchical folder structure inside your catalog path (default: billing/v1). Each product is a directory containing a product.yaml with optional nested variants:
billing/v1/
└── products/
└── weather-api/
├── product.yaml # Base product definition
└── variants/
├── starter/
│ └── product.yaml # Starter tier
├── pro/
│ └── product.yaml # Pro tier
└── enterprise/
└── product.yaml # Enterprise tierbilling/v1/
└── products/
└── api-credits/
├── product.yaml # Base product definition
└── variants/
├── small/
│ └── product.yaml # 1,000 credits
├── medium/
│ └── product.yaml # 10,000 credits
└── large/
└── product.yaml # 100,000 creditsVariants inherit from their parent and can override any attribute.
Product IDs are auto-generated from the directory structure. For example, weather-api/variants/pro/product.yaml becomes weather-api-pro.
Base Product Definition
A base product defines common attributes and the feature schema:
---
# MoneyMQ Product - API version v1
name: Weather API
description: Real-time weather data
product_type: service
unit_label: request
active: true
features:
requests_per_day:
name: Daily Requests
description: API calls included per day
forecast_days:
name: Forecast Range
description: Days of forecast data available
historical_data:
name: Historical Data
description: Access to past weather recordsThe base product defines the feature schema — what fields exist and what they mean. Variants then set specific values for each tier.
Creating Variants
Variants inherit from their parent and define tier-specific values and pricing:
---
# MoneyMQ Product - API version v1
name: Weather API - Starter
description: Perfect for hobby projects and prototypes.
features:
requests_per_day:
value: 100
forecast_days:
value: 3
historical_data:
value: false---
# MoneyMQ Product - API version v1
name: Weather API - Pro
description: For apps that need reliable weather data.
features:
requests_per_day:
value: 10000
forecast_days:
value: 14
historical_data:
value: true
price:
amounts:
usd: 29.00
pricing_type: recurring
recurring:
interval: month---
# MoneyMQ Product - API version v1
name: Weather API - Enterprise
description: Unlimited forecasts with dedicated support.
features:
requests_per_day:
value: -1 # -1 = unlimited
forecast_days:
value: 30
historical_data:
value: true
price:
amounts:
usd: 199.00
pricing_type: recurring
recurring:
interval: monthOne-Time Products
For one-time purchases like credit packs or licenses:
---
# MoneyMQ Product - API version v1
name: API Credits
description: Prepaid API call credits
product_type: good
active: true
features:
credits:
name: Credits
description: Number of API calls includedOne-Time Variants
---
# MoneyMQ Product - API version v1
name: 1,000 Credits
description: Good for testing and small projects.
features:
credits:
value: 1000
price:
amounts:
usd: 9.00---
# MoneyMQ Product - API version v1
name: 10,000 Credits
description: Best value for growing teams.
features:
credits:
value: 10000
price:
amounts:
usd: 79.00---
# MoneyMQ Product - API version v1
name: 100,000 Credits
description: For high-volume applications.
features:
credits:
value: 100000
price:
amounts:
usd: 599.00Nested Variants
Variants can have their own variants, enabling A/B testing and regional pricing:
billing/v1/products/weather-api/variants/pro/
├── product.yaml
└── variants/
├── annual/
│ └── product.yaml # Annual billing (20% off)
└── trial/
└── product.yaml # 14-day free trialNested variant IDs combine all levels: weather-api-pro-annual, weather-api-pro-trial. This recursive structure lets you experiment with pricing without cluttering your main catalog.
Product Schema Reference
Base Product Fields
| Field | Type | Description |
|---|---|---|
name | string | Product name |
description | string | Product description |
product_type | service | good | Product type (inherited by variants) |
unit_label | string | Display label (e.g., "per seat", "per request") |
active | boolean | Whether the product is active (default: true) |
features | object | Feature schema (name/description for each field) |
Variant Fields
| Field | Type | Description |
|---|---|---|
name | string | Product name (required for variants) |
description | string | Product description |
active | boolean | Override active status |
features | object | Feature values (key → { value: X }) |
price | object | Price configuration (see Configuring Prices) |
Features: Schema + Values
Features follow a schema-value pattern:
- Base product: Define the schema (name, description for each field)
- Variants: Provide the values
features:
requests_per_day:
name: Daily Requests
description: API calls included per day
support_tier:
name: Support Level
description: Response time guaranteefeatures:
requests_per_day:
value: 10000
support_tier:
value: "24h response"This pattern enables consistent feature displays across your pricing page while allowing each tier to set its own limits.
Next Steps
- Configuring Prices — Subscription, one-time, and usage-based pricing
- Using the Catalog — Query products via the SDK
- Deploying Updates — Ship changes with GitOps