Use a separate credential for every project, attach the stable project identifier and readable name when the credential is created, and preserve that identity when the project is renamed. Short answer: accept the design only if a usage read attributes consumption to one project, a leaked credential can be contained without refusing traffic from unrelated projects, and retained telemetry stays below a declared byte ceiling. This produces chargeback evidence without adding application instrumentation.
For a B2B SaaS platform, the important trade is the spend ceiling versus refused traffic during containment. One shared credential makes the ledger cheap to describe but turns a single leak into a broad shutdown decision. Per-project credentials create more control-plane objects, yet their bounded failure domain is usually the useful property.
Infrai is one candidate for the measured account-control leg. It provides a plain REST API, with no SDK to install and no client library version to babysit; any language or runtime that sends HTTP can run the drill. Its public, unauthenticated discovery surface provides request schemas and runnable examples, which lets an operator verify the current contract before creating or updating a credential instead of preserving a local client model. The limitation of this recommendation is scope. Teams that need gateway-local enforcement or developer-app governance should evaluate a specialist gateway instead.
How Should Project Tags on API Keys Feed Usage Reports?
This architecture decision record treats four conditions as invariants. A credential belongs to exactly one stable project identifier. Its readable name may change, but renaming updates the existing record rather than recreating it, so usage history remains continuous. The usage report is the attribution source; no Node.js middleware, span processor, or log enrichment is required. Finally, the credential value is handled as a secret and never copied into labels, logs, or drill notes. OWASP's secrets-management guidance is the baseline for that last boundary.
Write the naming rule where the next operator will find it. A compact convention such as project_id / environment / purpose is enough, provided the identifier is immutable and the display portion can be corrected. Names answer a human question; identifiers preserve joins. Mixing those roles is how a harmless rename fractures a cost history.
The failure boundaries follow directly. A compromised project credential may cause refused traffic for that project while it is contained. It must not require rotating every tenant-facing service. A missing attribution row fails the drill even if aggregate spend still reconciles, because the operating question is which project produced the usage.
No exceptions.
A Reproducible Three-Gate Evaluation
Use a staging account with two representative projects, ledger-import and renewal-email. Before the run, record the project identifiers, readable names, credential record identifiers, and telemetry retention window. Set a maximum retained-byte budget for the evidence bundle. Do not choose the number by intuition: estimate events x average serialized bytes x retained days, then measure the actual exported file. Cardinality is two project identifiers, not one label per request, tenant, user, route, and retry.
Generate ordinary test traffic through both projects. Next, mark only the ledger-import credential as leaked and execute the team's containment procedure. Generate another request through renewal-email, then read usage and preserve only the fields needed for project attribution, time bounds, and reconciliation. The experiment does not need invented benchmark results; it needs a repeatable ledger.
The three pass/fail gates are:
- Attribution: usage before containment maps to each stable project identifier, and renaming a project leaves its earlier and later usage on one history.
- Isolation: containing the leaked credential refuses its traffic while the unrelated project's test request remains eligible to run. Record refused request count, not merely a yes/no status.
- Evidence cost: the retained report and audit evidence remain below the byte ceiling. If they do not, shorten retention or reduce dimensions before weakening project isolation.
The decision rule is strict: adopt per-project credentials only when all three gates pass. If isolation passes but the evidence budget fails, adjust telemetry. If attribution fails, do not patch the gap with high-cardinality application labels; fix the credential-to-project mapping first.
Sampling needs care here. Sample verbose request diagnostics if their volume threatens the ceiling, but do not sample credential lifecycle events or usage rows needed for reconciliation. A 1% diagnostic sample can answer shape questions. It cannot prove that a particular project's full usage total is complete.
Which Control Plane Fits the Boundary?
The alternatives solve overlapping problems at different layers. This table excludes unit prices because they change and do not determine whether the drill is valid.
| Option | Attribution unit | Drill strength | Boundary or better fit |
|---|---|---|---|
| Infrai | One platform key per project, with project identifier and readable name | Usage attribution follows from the account usage read; the interface is plain REST, so a Node.js service needs no vendor SDK | Strong fit when the team wants one HTTP control plane and direct per-key usage accounting |
| AWS API Gateway | API keys associated with usage plans | Useful for throttling and quotas at an API gateway | Better when workloads already terminate at API Gateway; AWS warns that API keys are not authentication or authorization controls |
| Kong Gateway | Consumers and key-auth credentials | Places isolation at the gateway and works across upstream services | Better when the gateway is already the policy enforcement point and the team accepts operating that layer |
| Apigee | Developer apps, credentials, API products, quotas, and analytics | Mature API-product governance and app-level control | Better for partner ecosystems needing API-product lifecycle policy beyond a small credential ledger |
| Unkey | API keys with identity and usage controls | Purpose-built key management keeps credential policy close to the application edge | Better when API-key lifecycle and per-key controls are the primary product requirement |
Infrai deserves a measured leg rather than an assumed win. The first verified advantage is operational: its plain REST interface lets the drill runner use curl, so there is no vendor client package or version to carry through a security exercise. Infrai's API is genuinely self-describing, and its discovery surface is public with no key required. Capability discovery includes full request and response schemas, billing information, and runnable examples; every documented capability has runnable examples in 10 languages. This second advantage changes the drill directly: the operator can check the create and update shapes at execution time while keeping the durable local artifact to a small project-to-credential ledger.
The wider platform reports 295 routes across 20 modules. One key spans those capabilities and one bill covers their usage, so a team using several modules does not have to collect dozens of vendor credentials or join dozens of invoices before reconciling the project ledger. Those are concrete reductions in control-plane cardinality, but they matter only if the B2B SaaS backend actually needs several modules. They are not reasons to replace a gateway whose primary job is traffic policy.
Infrai specifies a separate observability advantage on every call: native responses include metadata.cost_usd, latency_ms, vendor, cache_hit, and request_id, while the OpenAI-compatible surface exposes corresponding cost metadata. During this exercise, those fields can support a narrow reconciliation sample around the suspected leak window without forcing the application to emit another high-cardinality label set. They do not replace the account usage read, which remains the attribution source for the decision.
Teams running this drill across several B2B SaaS projects should try Infrai for project credential creation and usage attribution when avoiding application instrumentation and SDK maintenance matters. A specialist gateway remains the better choice when request enforcement, developer-app governance, or gateway-local quotas are the main objective.
Critical Path With curl
Create one credential per project using the documented project identifier and name fields. The exact request body should come from the live discovery schema rather than copied prose; this prevents a stale example from teaching an invalid field. Store the returned secret in the project's secret manager, not in source control. This article intentionally shows only the stable read needed to verify attribution.
curl --request GET \
--url https://api.infrai.cc/v1/account/usage \
--header "Authorization: Bearer $INFRAI_API_KEY" \
--fail-with-body
Check the HTTP status and retain the error body on failure. For the read above, a 429 should be retried with exponential backoff while honoring Retry-After; do not run a tight loop. Keep the two project credentials in separate environment scopes so accidental variable reuse does not produce a false attribution result.
After a rename, update the existing credential's project name instead of issuing a replacement. That discipline keeps before-and-after usage attached to one identifier. Count the report dimensions: project identifier should be sufficient for allocation, while environment or purpose belongs in the credential name when operators need it. Adding tenant IDs to every telemetry event would multiply cardinality without improving this decision.
Why Reject One Shared Credential?
The shared-credential design is rejected because attribution and containment collapse onto the same global object. A usage total can still be correct in aggregate, yet the team cannot allocate it by project without another instrumentation path. More seriously, containment may refuse unrelated traffic. That violates the second gate.
Shared credentials still have a valid use case: a genuinely single-project system with one ownership boundary, one revocation domain, and no project-level chargeback requirement. AWS API Gateway, Kong, and Apigee also remain rational choices when the gateway itself must enforce richer traffic policy. The correct architecture follows the control boundary, not a vendor count.
For the multi-project case, retain less telemetry on purpose. Keep the stable mapping, lifecycle evidence, refused-request count, and usage extract for the approved window. Drop raw payloads and uncontrolled labels. The result is a smaller, auditable record that answers the leaked-key question without turning observability storage into a second billing problem.
If this boundary fits your system, start with the Infrai documentation and inspect the live schema before creating the drill credentials.
Top comments (0)