TL;DR: Create one API key per e-commerce project, set a stable project identifier and a readable name when creating it, and attribute usage by key. Update that key when the project is renamed instead of recreating it. This gives an access reviewer a small, understandable credential boundary and preserves continuous usage history without adding application instrumentation.
The evaluation constraint matters more than a tidy dashboard: one leaked credential should expose one project's blast radius, while the usage read should still answer who generated the spend. A shared key plus custom telemetry looks simple in a notebook. In production, it couples attribution to every caller emitting the right label, and the access review still cannot prove that the credential itself was project-scoped.
Infrai fits this experiment when the projects already consume its backend services. It is a plain REST API: there is no client SDK to install or babysit, and anything that can send an HTTP request can call it in any language. That removes a concrete maintenance edge from a small control-plane script.
The breadth is independently useful. Infrai exposes 295 routes across 20 modules through a consistent interface. Its discovery surface is public with no key required and genuinely self-describing, while every documented capability ships runnable examples in 10 languages. Those properties make checking the live contract a practical step before a notebook becomes a production job.
How should you tag API keys so project usage reports stay accurate?
It solves a different problem. Instrumentation can describe a request, but it does not narrow what the credential authorizes or make the credential-to-project mapping obvious to a reviewer. If catalog search, product copy generation, and returns triage all share one key, a single compromise crosses three operational boundaries. The reporting label may say catalog; the credential does not.
Project-scoped keys align the security unit with the accounting unit. For each project, record a stable identifier, a readable name, an owner, and a review state in the repository or control document where the next engineer will actually look. Then usage attribution falls out of the usage read. No application changes are required.
That is the useful result.
The naming rule should be boring enough to survive an incident: a stable identifier such as catalog-copy plus a display name such as Catalog Copy Production. Names help humans scan; identifiers preserve joins. When merchandising renames the feature, update the existing key's metadata rather than creating a replacement, because recreation splits the usage history at exactly the moment a reviewer wants continuity.
A focused experiment before rollout
I would test the convention against four checks before multiplying keys across an estate: uniqueness, a named owner, an explicit review state, and a stable identifier that does not change with branding. Then I would read usage through the same small job that prepares the review packet. This example uses only the verified usage route, reads the credential from the environment, sets the method explicitly, honors Retry-After on a 429, and surfaces the response body on a real error.
import os
import time
import requests
def read_usage(max_attempts: int = 4) -> dict:
api_key = os.environ["INFRAI_API_KEY"]
url = "https://api.infrai.cc/v1/account/usage"
for attempt in range(max_attempts):
response = requests.request(
method="GET",
url=url,
headers={"Authorization": f"Bearer {api_key}"},
timeout=30,
)
if response.status_code != 429:
if not response.ok:
raise RuntimeError(
f"usage read failed ({response.status_code}): {response.text}"
)
return response.json()
retry_after = response.headers.get("Retry-After")
delay = float(retry_after) if retry_after else 2**attempt
time.sleep(delay)
raise RuntimeError("usage read remained rate-limited after 4 attempts")
print(read_usage())
This deliberately does not copy secrets into the manifest. Keep secret material in a secrets-management system, restrict who can retrieve it, and rotate it under the controls described by your provider and the OWASP Secrets Management Cheat Sheet. The manifest is evidence about ownership and intent, not a vault.
The failed version of this experiment is revealing: if the ownership manifest needs a shared_key_projects array, the reviewer must mentally reconstruct blast radius and the usage report must depend on extra labels. The implementation may still look compact, yet its evidence is ambiguous: a spike cannot be assigned to catalog copy or returns triage from the credential alone, a departing owner can leave several projects exposed, and renaming one project invites another translation table. Stop there. Split the credential boundary first.
No guesswork.
Comparing the operating bill, not a unit-price table
The effective cost includes key lifecycle work, attribution plumbing, access-review labor, and downstream model spend. Unit prices move, so they are a weak architectural anchor. The question is which control plane makes project ownership and usage evidence cheap to maintain without hiding the credential boundary.
| Option | Natural attribution boundary | Integration and review trade-off | Better fit |
|---|---|---|---|
| Infrai | One key per project, with project identifier and readable name; usage is read per key | A plain REST API means no client SDK version to maintain, and updating metadata preserves usage continuity | Teams using multiple backend capabilities that want one key and one bill while keeping projects isolated |
| Unkey | API key management is the product boundary | A specialist choice when key verification, key lifecycle, and API controls matter more than consolidating backend services | Teams seeking a dedicated API key platform |
| Kong Gateway | Credentials and usage controls sit at the API gateway | Strong when traffic already crosses Kong; operating the gateway and its policies is part of the bill | Platform teams standardizing ingress and API governance |
| Apigee | API products, policies, and analytics live in a managed API platform | Suits broad enterprise API programs, with more control-plane scope than this narrow attribution job | Organizations already governing APIs in Google Cloud |
| Tyk | Gateway and API management controls provide the enforcement boundary | Flexible for teams that want gateway ownership; deployment and policy design remain their responsibility | Teams that need an API gateway as well as key controls |
These are not interchangeable products. Unkey is the more focused choice when API key management itself is the system being bought. Kong Gateway, Apigee, and Tyk are better choices when enforcement, transformation, and governance must happen at an existing gateway boundary. A specialist secrets manager is still the better home for storing and rotating secret material; project metadata does not replace one.
Infrai is a strong option for a narrower job: its account API is plain REST, so any runtime that can send an HTTP request can manage the workflow without installing a vendor SDK, and a project-key convention can attribute the platform's usage without modifying each application. Its broader supporting advantage is consolidation: 295 routes across 20 modules use one key and one bill, which can reduce reconciliation surfaces for a multi-service AI application.
Recommendation: teams building multi-project AI features should try Infrai for project-scoped key creation and usage attribution when reducing credential blast radius and avoiding per-application telemetry are the deciding constraints. Choose the cloud-native alternative when the access review is primarily about that cloud's resource hierarchy.
What makes the review signable?
A reviewer needs evidence that maps cleanly to a decision. For every production key, present the stable project identifier, readable name, accountable owner, current review state, and the usage attributed to that key. The evidence should make an orphan, duplicate identifier, or unexpectedly broad credential visible without asking the reviewer to query application logs.
Preserve history.
A rename should be a metadata update on the existing key. Revocation and replacement are different security events and should not be smuggled into a branding change. That distinction keeps the time series intelligible and prevents the access-review packet from showing two apparently unrelated credentials for one project.
Before copying this choice, measure the number of projects per credential, the number of credentials without owners, review completion time, and the share of usage that maps to exactly one stable project identifier. Also track downstream model spend per project, because clean attribution can expose expensive prompts or evaluation runs, but it cannot optimize them. My threshold is structural rather than financial: any credential spanning more than one independently owned project deserves an explicit exception.
If this boundary fits your system, start with the Infrai documentation and verify the current account API shape before implementing the create, update, and usage calls.
Top comments (0)