API Pricing Strategy

Context & Problem

The public API launches with v3.0, and we need a pricing model before the beta opens. Enterprise customers have asked for predictable costs, while smaller teams want to start without commitment. The model we choose sets expectations we cannot easily change later.

Constraints

• Billing infrastructure supports metering from November.
• Two enterprise renewals in Q4 depend on a published price.
• Must stay competitive with the two closest alternatives.

Options Considered

• Option 1 — Usage-based pricing Chosen

  Charge per thousand API calls with a free monthly allowance. Scales with customer value and lets small teams start free.

• Option 2 — Flat tiers

  Three fixed price points. Predictable for customers, but overcharges light users and caps our upside on heavy ones.

• Option 3 — Seat-based pricing

  Bundle API access into existing seats. Simplest to bill, but disconnects price from the cost of serving requests.

Outcome & Rationale

We are going with usage-based pricing. It matches cost to value, removes the barrier for new teams, and is the only option the billing work already underway supports without a rebuild.

Supporting Documents

Comments

• 
  Liam Zhang 2 days ago

  Agreed on usage-based, but we should publish a cost calculator alongside it or support will field the same question all quarter.

• 
  Maya Johnson Yesterday

  Calculator is on the launch checklist. Legal has signed off on the free allowance wording.

Add a comment

Decision Details

Owner

Jessica Collins

Category

Strategy

Priority

High

Created

28 Aug 2026

Decided

9 Sep 2026

Tags

Pricing API v3.0

Approvals

• 

  Maya Johnson

  Head of Product

  Approved
• 

  Liam Zhang

  Engineering Lead

  Approved
• 

  Sofia Lopez

  Finance

  Pending

Timeline

1. Approved

   Maya Johnson · 9 Sep 2026

2. Submitted for review

   Jessica Collins · 4 Sep 2026

3. Draft created

   Jessica Collins · 28 Aug 2026

Linked Items