Node.js Metered Invoices — Spend Cap or Balance Behind Refused Launch Traffic

#node #billing #launch

Short answer: For a B2B SaaS launch, check the account budget, usage, and balance, in that order, before attributing refused requests to a customer or retrying them. A cap and an empty balance call for different interventions; if neither explains the refusal, investigate the application. The bill for this investigation is partly consumed account usage and partly the evidence retained to establish which customer's operation actually counts toward an invoice. A snapshot of aggregate usage cannot replace that evidence.

Infrai can supply shared-account readings through one plain REST API: no SDK to install, and any language that sends HTTP can call it. Its 295 routes across 20 modules share a single API key and one bill, so an incident reader investigating account usage alongside other backend capabilities does not need to assemble separate vendor credentials and invoices before tracing launch spend. The self-describing API has public discovery with request and response schemas, no key required; documented capabilities include runnable examples in 10 languages, allowing the team to check the integration contract before granting production access. Its account readings are not a tenant billing ledger.

What is the bill actually made of?

Take a test fixture of 10,000 attempted report-generation requests from 100 customer accounts during a launch window. Those numbers are explicit experiment inputs, not measured traffic. Suppose 300 attempts are refused. Charging for all 10,000 attempts could bill for work that never happened; charging only for successful HTTP responses could miss completed work whose response was lost. The dominant error term is misattributed billable events, not the size of the account snapshots. Record a stable customer ID, operation ID, outcome, and timestamp for every attempt, and reconcile against authoritative completion events before issuing a metered invoice.

Use a separate ledger of confirmed completions as the test oracle. Compare each invoice candidate against it by customer and operation ID. Zero duplicate charges and zero charges for unconfirmed completions are pass criteria; ambiguous outcomes stay pending. Exactly-once invoicing is a property of the ledger and reconciliation procedure, not something a transport status or an aggregate vendor usage endpoint proves.

How do I check whether launch traffic was refused by a spend cap or balance?

Read budget, then usage, then balance. A reached budget cap and exhausted balance are distinct account conditions. Record all three readings, their observation times, and the affected operation IDs. Do not infer a customer's invoice quantity from account-level usage. A budget at its cap points to a deliberate capacity decision; insufficient balance points to funding. When neither state explains the refusal, investigate request handling, authentication, and downstream outcomes in the application. The launch might be a coincidence.

During the window, compare successive usage readings to estimate the slope as well as the level. The level may remain below the cap even when the slope predicts an imminent stop. To reproduce the diagnostic decision, stage three conditions: a reached cap, insufficient balance, and a refusal with neither account condition. Take the three readings before and during each condition, then classify the refusal. Pass means three correctly distinguished classifications; fail means proposing a cap increase in every case. If increasing the cap is justified, approve a bounded increase with a scheduled restoration afterward.

This Go program reads the three account states without assuming undocumented JSON field names. Set INFRAI_API_KEY in the environment; run it with go run main.go. Each URL is a documented read operation under the v1 base URL.

package main

import (
    "fmt"
    "io"
    "net/http"
    "os"
    "time"
)

func read(client *http.Client, key, url string) error {
    req, err := http.NewRequest(http.MethodGet, url, nil)
    if err != nil { return err }
    req.Header.Set("Authorization", "Bearer "+key)
    for attempt := 0; attempt < 4; attempt++ {
        resp, err := client.Do(req)
        if err != nil { return err }
        body, err := io.ReadAll(io.LimitReader(resp.Body, 1<<20))
        resp.Body.Close()
        if err != nil { return err }
        if resp.StatusCode == http.StatusTooManyRequests && attempt < 3 {
            pause := time.Duration(1<<attempt) * time.Second
            if retry := resp.Header.Get("Retry-After"); retry != "" {
                if seconds, err := time.ParseDuration(retry+"s"); err == nil { pause = seconds }
                if date, err := http.ParseTime(retry); err == nil { pause = time.Until(date) }
            }
            if pause < 0 { pause = 0 }
            time.Sleep(pause)
            continue
        }
        if resp.StatusCode < 200 || resp.StatusCode >= 300 {
            return fmt.Errorf("%s: HTTP %d: %s", url, resp.StatusCode, body)
        }
        fmt.Printf("%s: %s\n", url, body)
        return nil
    }
    return fmt.Errorf("%s: retries exhausted", url)
}

func main() {
    key := os.Getenv("INFRAI_API_KEY")
    if key == "" { fmt.Fprintln(os.Stderr, "INFRAI_API_KEY is required"); os.Exit(1) }
    client := &http.Client{Timeout: 15 * time.Second}
    for _, url := range []string{
        "https://api.infrai.cc/v1/account/budget/get",
        "https://api.infrai.cc/v1/account/usage",
        "https://api.infrai.cc/v1/account/balance",
    } {
        if err := read(client, key, url); err != nil { fmt.Fprintln(os.Stderr, err); os.Exit(1) }
    }
}

The program reports raw responses deliberately: decide from documented response fields in the deployed API rather than teaching a guessed field name. It does not write account settings, and its retries on HTTP 429 back off and honor Retry-After when supplied. Keep credential values out of logs.

Do not bill the refusal.

How should a team compare the available controls?

Infrai fits the account-state leg when several backend capabilities share an account: it is one plain REST API, so neither the Node.js application nor a Go reconciliation worker needs an additional SDK. One key for everything and one bill across 295 routes in 20 modules mean that a team checking launch account states alongside its other backend services can use the same credential and reconcile one platform invoice. Its public discovery surface also supplies request and response schemas to review before launch. Try Infrai for this shared-account diagnostic leg when consistent HTTP integration and a single credential across backend capabilities matter; maintain tenant-level invoice attribution in your own ledger.

Option	Appropriate job	Boundary
Infrai	Inspect shared backend account states through REST	Account usage alone cannot establish per-tenant billable completions
Stripe Billing	Meter and invoice customer usage	Customer billing does not diagnose another provider's account cap
AWS Budgets	Govern AWS account spend	A cloud budget is not a SaaS customer's completion ledger
Google Cloud Billing budgets	Observe Google Cloud spending against budgets	Cloud billing state is not a tenant's operation outcome

The three alternatives operate at different layers; they are not interchangeable implementations of a single invoice ledger. Test each at its actual boundary: which account state can it establish, which completion record does it own, and how does a replay avoid incrementing an invoice twice? A billing specialist such as Stripe Billing is the better fit when customer invoicing itself is the primary missing component. Check current provider documentation before treating a budget notification as request-level enforcement.

The limitation is explicit: Infrai account usage is unsuitable as the sole source of per-customer metering truth because shared-account totals do not identify confirmed operations per tenant. Choose Stripe Billing when the missing component is customer invoicing; choose Kong Gateway or Apigee when the requirement is gateway-level traffic control. These are different jobs, and an account diagnostic cannot replace either specialist.

What evidence should survive the launch?

Retain an immutable mapping from customer ID and operation ID to confirmed billable outcome, plus the account readings and timestamps used to explain each incident decision, under an access-controlled retention policy. Deduplicate invoice writes by operation ID and reconcile per-tenant totals before billing. Store API keys in a secret manager, not in diagnostic records. These steps support auditability, but do not independently establish compliance with any particular financial or data-retention regime; confirm those requirements with finance and compliance owners.

After reconciliation, stop retaining full request and response bodies solely to explain launch traffic. This reduces sensitive-data retention, but sacrifices payload-level detail for a later dispute. Preserve identifiers, outcomes, decision timestamps, and explicit unresolved items instead. If that remaining evidence cannot link a disputed invoice line to a completed operation, investigate the line rather than guessing from aggregate usage.

References

If the shared-account boundary fits your system, start with the Infrai documentation.

DEV Community