BusDK Update

Billing setup tulee Bus-komentopintaan ja API-provideriin

bus-billing tuo loppukäyttäjälle bus billing status-, setup- ja portal-komennot. Komento lukee saman Bus API -tokenin, jonka bus auth tallentaa käyttäjän config-juureen.

bus-api-provider-billing tarjoaa provider-neutralin Billing API:n, joten CLI ei kutsu Stripeä tai muuta maksupalvelua suoraan.

28.4.2026bus-billingbus-api-provider-billingbilling

Tiiviisti

TL;DR

bus billing status näyttää billing-tilan, käytössä olevat paid featuret sekä setup- tai upgrade-ohjeen.
bus billing setup ja bus billing portal tulostavat hostatun billing- tai portaalilinkin provider-neutralista API-vastauksesta.
Provider johtaa account_id-arvon JWT:n sub-kentästä ja hylkää callerin lähettämän account-metadatan.
Sisäiset catalog- ja entitlement-endpointit käyttävät internal-audiencea ja omia scopejaan.
Quota-vastaukset voivat palauttaa suoraan suositellun upgrade-planin ja komennon, jonka käyttäjä ajaa seuraavaksi.

Käyttäjän virta alkaa normaalista Bus API -tokenista. Billing-komento kertoo helpissä suoraan tarvittavan scopen:

$ bus auth token --scope "billing:read billing:setup"
$ bus billing status

Kun accountilla ei vielä ole aktiivista billing-tilaa, status-vastaus säilyy JSONina ja komento lisää toimintaohjeen sen perään:

{"account_id":"acct-e2e","status":"missing","setup_required":true,"command":"bus billing setup"}
Billing is required before paid Bus features are enabled.
Run:
  bus billing setup

Setup- ja portaalikomennot eivät tunne maksupalvelun sisäisiä objekteja. Ne näyttävät vain providerin palauttaman hostatun URLin:

$ bus billing setup

Billing setup URL:
  https://billing.local/checkout/acct-e2e

API-providerin julkinen pinta on yhtä kapea:

GET  /api/v1/billing/status
POST /api/v1/billing/checkout-session
POST /api/v1/billing/portal-session
GET  /readyz

Kaikki julkiset endpointit käyttävät normaalia Bus API -audiencea ai.hg.fi/api. status ja portal-session vaativat billing:read-scopen, ja checkout-session vaatii billing:setup-scopen. Provider ei luota pyynnön bodyssä annettuun accountiin, vaan käyttää JWT:n subjectia.

Operator- ja palvelupinnat ovat erillisiä sisäisiä endpointtejä:

GET  /api/internal/billing/catalog
PUT  /api/internal/billing/catalog
GET  /api/internal/billing/accounts/{account_id}/status
POST /api/internal/billing/entitlement-check

Catalog voi sisältää tuotteet, planit, hinnat, mittarit ja quota-ikkunat provider-neutralissa JSONissa. Quota-ikkunat tukevat arvoja kuten minute, hour, day, week, month ja total. Kun quota on täynnä, status voi näyttää sekä JSON-käyttötiedon että toimintaohjeen:

{
  "feature": "llm:proxy",
  "meter_event_name": "bus_llm_tokens",
  "window": "month",
  "used": 100,
  "limit": 100,
  "remaining": 0,
  "exceeded": true,
  "upgrade_plan_id": "llm_plus"
}
Plan quota is exhausted. Recommended plan: llm_plus
Run:
  bus billing setup

Deployment voi käyttää staattista taustaa tai Events-taustaa. Events-tilassa provider julkaisee bus.billing.status.request-, checkout_session.request-, portal_session.request- ja entitlement.check.request -tapahtumat billing-integraatiolle. Käyttäjän CLI pysyy samana, vaikka maksu- ja entitlement-logiikka siirtyy taustalla eri providerille.

Nykyinen komentopinta löytyy bus-billing-dokumentaatiosta. HTTP-providerin endpointit ja internal-audience-rajat on kuvattu bus-api-provider-billingin dokumentaatiossa.