Pricing & Metering — Reference

Reference structure for documentation and quoting. Not a live rate card — actual pricing requires a billing system consuming usage_events (not yet built, see AUTH_ARCHITECTURE.md) and sign-off from finance/counsel before any number here is quoted to a customer as binding.

Subscription tiers

Plan Price Included Notes
Developer $0/month 10,000 calls, sandbox only, limited datasets No SLA. Maps to the developer role.
Growth $99–$299/month 100,000 calls, production API, webhooks, usage dashboard Maps to customer role.
Business $500–$2,500/month 1M+ calls, advanced APIs, higher rate limits, support Maps to partner role.
Enterprise Contract Volume pricing, partner APIs, bulk datasets, SLA, dedicated credentials, custom scopes Maps to partner role with negotiated scope grants.
Strategic / Utility Contract Trading, settlement, DER, grid, market integration, private endpoints, dedicated infrastructure Maps to trading_partner role — the only role whose default bundle includes trading:execute, and even then only against a environment=production credential (enforced in code, not just policy — see AUTH_ARCHITECTURE.md).

Per-call metering (implemented and recording today)

Every authorized request is billed against the scope that authorized it, mapped to a billing code — not against the raw endpoint path. This mapping is real code (BILLING_CODE in app/core/scopes.py) and every number below is currently being written to usage_events on every matching request in this session's testing:

Billing code Reference price Example operation
BASIC_CALL $0.001 GET /plans, GET /customers/{id}, GET /usage/{id}
ADDRESS_SERVICEABILITY $0.005 GET /utilities/lookup
MARKET_QUERY $0.01 (reserved — market:read scope exists, no endpoint yet)
FORECAST_CALCULATION $0.025 GET /usage/{id}/forecast
QUOTE $0.05 (reserved — quote:create scope exists, no endpoint yet)
ENROLLMENT_TRANSACTION $0.25 POST /enrollments
COMPLEX_OPTIMIZATION $0.50+ POST /exchange/transactions (trading:execute)

catalog:read (e.g. GET /utilities) and admin are never billed.

Why documentation drives adoption, not the reverse

The intended growth loop: more documentation → more integrations → more calls → more revenue, not less documentation → fewer people understand the API → fewer integrations. This is why API_TIERS.md argues for publishing use cases, endpoint categories, and example request/response bodies openly, even though the underlying implementation, models, and infrastructure stay proprietary — see that document for the reasoning and the classification matrix.