feat: source Landing Page pricing from Vela public APIs

[nettee]

What problem are we trying to solve?

The Landing Page pricing screen currently maintains Personal and Team pricing, introductory discounts, and monthly credit grants as static data. Vela has the authoritative billing and entitlement data, so independently maintained values can drift after a price or grant change.

This issue is the single rollout tracker across both repositories:

1. Vela API development
2. Vela production rollout
3. Open Design Landing Page integration
4. Landing Page production rollout

Confirmed scope and contract decisions

• Add two new unauthenticated Public APIs in Vela. Do not remove authentication from, or expose the DTOs of, the existing private billing APIs.
• GET /api/v1/public/plan-prices
  • Personal and Team plans
  • Monthly and yearly billing amounts
  • Standard introductory offer amount, discount, duration, and eligibility
  • Team billing unit and minimum seat count
• GET /api/v1/public/plan-entitlements
  • Personal monthly credit grant in USD
  • Team monthly credit grant per seat in USD
• Annual savings relative to monthly billing is not part of the API contract. The Landing Page calculates this from monthly and yearly prices.
• Internal credit units are not part of the Public API. Entitlement values are returned in USD only, for example monthlyCreditGrantUsd: "20.00".
• Public DTOs must not expose Stripe price IDs, Stripe coupon IDs, coupon source IDs, user coupon instances/templates, current subscription state, or user-specific offers.
• Model lists, Coding Plan access, RPM, concurrency, deploy limits, and other plan capabilities are out of scope for this issue.
• Vela owns commercial facts and entitlement values. The Landing Page owns localization, marketing copy, formatting, and derived display values.

Phase 1 — Vela development

• Define independent Public API Zod/OpenAPI schemas and response types.
• Implement a dedicated public billing route/module; do not route through the private HTTP handlers.
• Implement a whitelist projection from Vela billing domain data to Public DTOs.
• Read active Personal plan amounts and standard intro offers from the configured Stripe commercial identities.
• Read active Team prices, intro offers, billing interval, billing unit, and minimum seats from team_billing_plan_catalog.
• Read Personal monthly grant USD from active membership_entitlements.
• Read Team monthly grant-per-seat USD from team_billing_plan_catalog.
• Return stable planId, schemaVersion, revision, and generatedAt fields.
• Add bounded public caching/ETag behavior and explicit 503 catalog_unavailable behavior when required pricing data cannot be resolved.
• Configure and verify CORS for production and preview Landing Page origins.
• Add tests for schema validation, active-plan filtering, price/discount math, USD conversion, deterministic ordering, and failure behavior.
• Add explicit redaction tests proving that Stripe IDs and user-specific/private fields cannot appear in either response.
• Add a consistency test requiring every publicly priced active plan to have a corresponding public entitlement entry.
• Open and merge the Vela PR.

Phase 2 — Vela rollout

• Deploy the Vela API changes to the pre-production environment.
• Smoke-test both endpoints without authentication and without cookies.
• Verify Personal monthly/yearly prices and intro offers against the corresponding Stripe configuration.
• Verify Team prices, discounts, minimum seats, and monthly grant USD against the active catalog.
• Verify cache headers, ETag behavior, CORS, error responses, and Public DTO redaction.
• Deploy Vela to production.
• Repeat production smoke tests and record the deployed Vela release/commit below.

Phase 3 — Landing Page integration

• Add typed clients/adapters for both Vela Public APIs.
• Join price and entitlement records by stable planId; reject incomplete or unknown required data instead of silently filling static defaults.
• Replace static Personal and Team price values with Public API data.
• Replace static intro-discount values with Public API data.
• Replace static Personal monthly grant and Team monthly grant-per-seat values with the USD entitlement fields.
• Calculate annual savings and monthly-equivalent display values in the Landing Page with one documented rounding rule.
• Keep localization, labels, feature copy, recommended badges, and layout in the Landing Page.
• Define a visible unavailable state and prevent stale/partial catalog data from presenting a valid purchase offer.
• Remove the superseded price, discount, and credit-grant constants and unused static mirrors.
• Update unit/contract tests for Personal and Team rendering, missing-plan behavior, malformed payloads, and API failures.
• Verify pricing cards, comparison content, CTA behavior, and structured pricing metadata in preview.
• Open and merge the Open Design PR.

Phase 4 — Landing Page rollout

• Deploy the Landing Page to preview/staging against the production-ready Vela Public APIs.
• Verify Personal and Team monthly/yearly switching on desktop and mobile.
• Verify intro-offer labels and eligibility copy.
• Verify annual savings calculated by the frontend.
• Verify USD monthly grants, Team per-seat wording, and minimum-seat totals.
• Verify behavior when either Public API is unavailable or returns incomplete data.
• Deploy the Landing Page to production.
• Perform a final production comparison against Vela/Stripe and record the deployed Open Design release/commit below.

Acceptance criteria

• No Personal or Team price, standard introductory discount, or monthly grant amount displayed by the Landing Page is manually duplicated in Landing Page source.
• Existing authenticated/private Vela billing APIs remain authenticated and retain their existing response contracts.
• Public APIs expose no user-specific data or Stripe/coupon identifiers.
• Landing Page annual savings are derived in the frontend from Public API price amounts.
• Public entitlements expose USD grant values only, with no internal credit-unit values.
• Both production deployments and their smoke-test evidence are linked from this issue.

Delivery links and evidence

• Vela PR: TBD
• Vela deployed commit/release: TBD
• Vela production smoke-test evidence: TBD
• Open Design PR: TBD
• Landing Page deployed commit/release: TBD
• Landing Page production smoke-test evidence: TBD

Rollback

• Vela Public APIs can be rolled back independently because no existing private endpoint is changed.
• Landing Page integration should be deployed only after the production Vela endpoints pass smoke tests.
• If Landing Page rollout fails, roll back the Landing deployment; do not restore long-lived hardcoded pricing as a silent runtime fallback.

[lefarcen]

Hey @nettee — this is a solid rollout tracker for a cross-repo pricing cut.

The separation you called out between Vela-owned commercial facts and Landing-owned presentation logic is the right boundary, and keeping annual savings as a frontend-derived value while explicitly redacting Stripe/user-specific fields from the new public DTOs covers the two failure modes we'd most want to avoid here.

One thing worth keeping tight as this moves: please keep the delivery-links/evidence section updated as each PR and production rollout lands, so the API contract, deployed commits, and smoke-test proof stay anchored in one thread instead of getting split across repo history.

[lefarcen]

Heads-up: PR #7239 is the current Landing-side follow-up for this rollout. It updates /pricing/ to respect the signed-in billing interval, pending/canceling states, and checkout restrictions, and it keeps the account chrome scoped to Pricing instead of re-enabling it across the rest of Landing.

Keeping this tracker open still makes sense until the broader Vela/API rollout and deployment evidence here are complete.

[lefarcen]

Quick rollout update: PR #7239 merged on August 21, 2026, so the Landing-side integration path is now in place for the signed-in pricing state work.

This tracker should stay open until the companion Vela public API work, production rollout, and the final deployment/smoke-test evidence are linked here as well. Once those land, the issue body will have the full end-to-end record in one place.