Skip to content

docs: add billable usage API enhancement proposal - #95

Open
mattdjenkinson wants to merge 3 commits into
mainfrom
docs/usage-query-api-enhancement
Open

docs: add billable usage API enhancement proposal#95
mattdjenkinson wants to merge 3 commits into
mainfrom
docs/usage-query-api-enhancement

Conversation

@mattdjenkinson

Copy link
Copy Markdown
Contributor

Summary

  • Proposes a billing usage-api server — the read-side counterpart to the existing durable usage pipeline — that exposes usage/cost as normalized, FOCUS-aligned rows scoped by billing account.
  • Grounds the motivation in a concrete finding: both cloud-portal (customer-facing) and staff-portal hold a shared, server-side Amberflo API key and call Amberflo's /usage endpoint directly, violating the "only the Submission Controller holds provider credentials" principle already established in usage-pipeline.md.
  • Keeps the billing service provider-agnostic by defining a new internal query interface for amberflo-provider to implement, rather than having this repo hold an Amberflo credential itself.
  • Scopes callers to cloud-portal, staff-portal, and datumctl, with implementation of each companion side (provider query endpoint, portal migrations, CLI command) explicitly out of scope for this doc.

Tracked by #94.

Test plan

  • Doc-only change — no code affected.
  • Review for consistency with usage-pipeline.md and payment-methods.md conventions.

Both cloud-portal and staff-portal call Amberflo's /usage endpoint
directly with a shared server-side API key, bypassing the billing
service entirely and violating the credential-isolation principle
already established in usage-pipeline.md. Proposes a provider-agnostic
billing usage-api that normalizes usage into FOCUS-aligned rows for
both portals and datumctl.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Reframes the CLI command from a deferred follow-up to a same-wave
companion: it's the first caller with no session/portal BFF behind
it, making it the cleanest validation that the endpoint's auth and
shape are actually self-serve-ready. Links the companion issue
(datum-cloud/datumctl#266).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Adds a field-by-field inventory against cloud-portal's and
staff-portal's MeterSeries/UsageFetchResult types (identical in
both) so the migration drops nothing currently shown to users, plus
a Provider Portability Guarantee spelling out that no Amberflo
identifier (meterApiName, customerId) may leak into the public
response -- the concrete bar for "can switch providers without the
portals noticing."

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant