UsageBox does not ship a customer portal today. What it can provide is the metering data a portal needs: raw usage events and monthly rollups tied to customers, subscriptions, meters, and charges. The portal itself belongs in your application or another downstream product.
What the portal should read
- Current usage quantities: read the same rollups your internal billing workflow uses.
- Meter names and units: translate internal identifiers into language customers recognize.
- Subscription context: show which plan or contract the quantity belongs to.
- Raw events for disputes: keep a drill-down path for support rather than pretending a rollup is an audit trail by itself.
Keep enforcement separate
A usage display is not a spend cap. UsageBox currently meters quantities; it does not synchronously block your product when a threshold is crossed. If you need hard limits, enforce them in the application path that owns the expensive operation and use metering as the evidence behind the decision.
A simple integration shape
- Your application emits usage events to UsageBox.
- UsageBox deduplicates retries and folds events into the correct monthly rollups.
- Your authenticated backend reads the customer's rollups.
- Your UI renders those quantities beside the plan limits or prices your own billing system knows about.
This separation is deliberate: the meter should stay useful even if you replace the portal, payment processor, or invoicing system later.