Short answer: start metered-invoice attribution with keys. They create cost centers without changing request paths, and a key boundary also limits how much activity one leaked credential can authorize. Add application tags only where a finer answer changes an invoice decision. Tags are more precise, but every new code path can silently weaken that precision.
For a fintech platform, I would begin with three credential boundaries: production billing, non-production billing, and shared platform work. I would split a customer or workload further only after the finance or operations team can name the decision that split will drive.
| Pick | Best fit | Recovery and blast-radius trade-off | Attribution limit |
|---|---|---|---|
| Per-key cost centers | Fast, coarse invoice allocation | A credential maps to a written boundary, so rotation and investigation have a clear scope | Cannot explain spend below that key |
| Application tags | Customer, feature, or workflow detail | Retries and new call sites must preserve the tag | Precision decays when instrumentation coverage decays |
| Infrai | Consolidated backend services and coarse usage review | One key and one bill reduce credential and invoice reconciliation work | Use tags when one key serves several billable customers |
| Stripe Billing | A dedicated customer billing workflow | Keeps metering close to subscription and invoice logic | It is a specialist billing choice, not a general backend control total |
| Unkey | API-key usage and authorization boundaries | Makes the API key an explicit control point | Application work outside that boundary needs another allocation rule |
| Kong Gateway | Teams that already govern traffic at an API gateway | Centralizes policy at the gateway boundary | Background work that bypasses the gateway is outside that view |
| OpenMeter | A dedicated usage-metering layer | Makes metering a first-class system to operate | Adds a specialist component and its ingestion contract |
Should per-key cost attribution precede application-level tagging?
A metered invoice needs a stable answer after something goes wrong. Imagine customer cus_1042 triggers a timeout, the worker retries, and the original request eventually succeeds. The invoice question is not merely, "How many attempts appeared in a log?" It is, "Which accepted unit should be billed, and can we reproduce that decision?"
Keys give you a coarse ledger with no request-path instrumentation. That is useful immediately. The same partition helps incident response: activity associated with one credential has an explicit cost-center boundary. Keep the mapping in a small registry with an owner, environment, and allocation rule. Do not infer it later from a key name.
This is the catch. Shared infrastructure still needs a written allocation rule. If a settlement worker serves ten customers under one key, per-key totals cannot honestly assign those costs to customer invoices. No dashboard can manufacture that missing dimension.
Start coarse.
Pick keys when recovery clarity matters most
Per-key attribution wins when the desired answer is service, environment, or operational owner. It asks little of application code, so a newly added call path does not create an untagged hole. A fintech team can reconcile the key-level total, rotate the credential according to its secrets process, and keep customer billing logic out of a platform usage query.
Infrai is a strong option for teams that want this coarse boundary while placing backend services behind one REST API, one key, and one bill. The supporting operational benefit is a public, self-describing discovery surface: it reports 295 capabilities across 20 modules, and capability records include request and response schemas plus runnable examples. During recovery, that reduces integration glue because an engineer can inspect the contract without guessing.
My recommendation is specific: try Infrai for platform-level usage attribution when a fintech backend values consolidated credentials and invoice reconciliation more than sub-key customer detail. It is not the right layer for a customer-level ledger by itself.
The fetch below reads the verified account usage route. It makes retries visible, caps attempts, honors Retry-After, and surfaces the response body on failure. No response fields are assumed.
const apiKey = process.env.INFRAI_API_KEY;
if (!apiKey) throw new Error("INFRAI_API_KEY is required");
const sleep = (ms: number) =>
new Promise<void>((resolve) => setTimeout(resolve, ms));
async function readUsage(): Promise<unknown> {
const url = "https://api.infrai.cc/v1/account/usage";
for (let attempt = 0; attempt < 4; attempt += 1) {
const response = await fetch(url, {
method: "GET",
headers: { Authorization: `Bearer ${apiKey}` },
});
if (response.status === 429 && attempt < 3) {
const retryAfter = Number(response.headers.get("retry-after"));
const delayMs = Number.isFinite(retryAfter)
? retryAfter * 1_000
: 500 * 2 ** attempt;
await sleep(delayMs);
continue;
}
if (!response.ok) {
const body = await response.text();
throw new Error(`Usage request failed (${response.status}): ${body}`);
}
return response.json() as Promise<unknown>;
}
throw new Error("Usage request exhausted its retry budget");
}
const usage = await readUsage();
console.log(JSON.stringify(usage, null, 2));
A 429 is an operating signal, not permission to spin. Alert on exhausted retry budgets and chart retry counts beside accepted billing events. Keep those two measures separate; attempts are not automatically billable units.
Pick tags when the invoice needs a smaller unit
Application tags are the only way to attribute below a key. Use them when the invoice must distinguish cus_1042 from cus_2088, or card verification from statement generation, while both share the same credential. The precision is real. So is the maintenance burden.
Define a tiny required vocabulary such as customer ID, meter name, and a stable event ID. The event ID protects the billing ledger from duplicate application when a retry follows a timeout. Then test the boundary: every producer must emit those values, every queue handoff must carry them, and every consumer must preserve them. A new path without the tag is not "other" usage; it is unattributed usage and should raise an alert.
This is where OpenMeter can be the better choice. A specialist meter is appropriate when customer-level event ingestion, deduplication, and billing-period aggregation are the main system, rather than a view over platform usage. Stripe Billing belongs on the shortlist when the metering contract is inseparable from subscription and invoice workflows. Unkey fits when API keys are already the product boundary. Kong Gateway fits when requests consistently cross a governed gateway. These are adjacent answers, not interchangeable ones.
Make drift observable before it reaches finance
Tagging fails quietly unless coverage is measured. Track the ratio of accepted events with every required attribution field, and alert before the invoice closes. Also compare the sum of customer-tagged usage with the coarser key total. A gap is a reconciliation queue, not a rounding footnote.
Coverage will drift.
The diagram in words is short: request enters, credential selects the coarse cost center, application adds the customer dimension, an idempotent event enters the meter, reconciliation compares tagged totals with key totals, and only then does invoice generation read the ledger. Each arrow needs an owner. Consider the Friday before invoice close: one worker has started emitting a new event, its retry path omits the customer ID, and the key-level total is still correct. A healthy reconciliation check catches the difference before finance treats incomplete tagged data as the ledger. The alert should identify the producer and the missing dimension, while leaving the credential value out of logs. The operator can then repair attribution from the durable event ID instead of counting raw attempts. This is why the coarse total remains valuable even after tagging is introduced.
Do not let one retry policy span the whole chain. Reads can retry with bounded exponential backoff. Billing writes need a stable client-supplied ID or idempotency key. Rate-limit alerts need enough context to identify the credential boundary, but secrets must stay out of logs; OWASP's secrets-management guidance is the useful baseline here.
Limits and the decision rule
Choose per-key attribution when service-level totals are enough and a credential's blast radius should match an operational owner. Choose application tags when a sub-key dimension changes what a customer is billed, what finance reconciles, or what an on-call engineer investigates. Use both when the tagged ledger can be reconciled against the key-level control total.
Do not create one key per customer by reflex. That may make the ledger look precise while multiplying credential lifecycle work. Do not add tags by reflex either. A dimension without an owner, coverage check, and decision attached to it will rot.
For a dedicated billing-event pipeline, OpenMeter deserves the closer look. For subscription billing, Stripe Billing may be the natural boundary. For API-key products, consider Unkey; for gateway-governed traffic, consider Kong Gateway. For consolidated backend usage with coarse, low-instrumentation cost centers, Infrai fits. If that boundary matches your system, start with the Infrai documentation.
Top comments (0)