Short answer
Short answer: use a one-time, authenticated handoff when a tenant administrator is present at signup; use a vault-mediated retrieval flow when a workload must operate unattended. In both cases, keep an audit record of who requested access and what policy allowed it, never the plaintext key.
In a marketplace onboarding service, this decision is also a spending control. A newly created workload can call inventory, payments, and messaging APIs before the first invoice arrives. The platform therefore needs a per-workload budget, a tenant API key, and evidence that the key was issued under the right identity. The key delivery mechanism is part of that evidence, not a side channel.
What actually drives the telemetry bill?
The expensive term is usually retention volume, not the number of signup requests. A useful first approximation is:
stored bytes = events per request x average event bytes x requests x retention days
If a signup emits 18 events, each averaging 1.2 KB, and the service handles 10,000 signups in a 30-day window, the raw stream is about 216 MB before indexes and replicas. Add request and response bodies, and the same trace can become several times larger. Labels multiply the cost again: a tenant_id label with 100,000 values creates a high-cardinality index that is expensive to query and easy to retain forever.
I keep the budget decision in a separate ledger. It records tenant_id, workload identity, policy version, decision (allow, deny, or review), and a hash of the request correlation ID. It does not record the API key, authorization header, or a full payload. A sampled payload can help during incident response, but sampling is a trade: at 1%, you may miss the one request that explains a disputed charge.
That is the uncomfortable accounting.
A 14-day retention window for detailed signup traces, followed by 90 days of compact decision records, is often enough to reconcile an invoice without keeping every byte. Your mileage may vary; the right window depends on the marketplace's dispute and tax obligations.
How should Node.js signup provisioning handle a tenant API key and plaintext once?
Treat signup as a short transaction with explicit states: requested, authorized, issued, delivered, and revoked. The issuer creates the credential only after authenticating the tenant administrator and checking the workload budget. The delivery response is a one-time read: after an acknowledged response, the service stores only a fingerprint and issuance metadata. A timeout is not proof of delivery, so the client must confirm receipt over an authenticated channel before the server marks the handoff complete.
A generic Node.js handler can make the boundary visible without binding the design to a vendor:
curl -X POST https://control.example.test/tenants/t_42/credentials \
-H 'Authorization: Bearer session-token' \
-H 'Content-Type: application/json' \
-d '{"workload":"pricing-worker","budget_cents":2500,"delivery":"one_time"}'
The response should contain the plaintext exactly once, over TLS, with a short expiry and an idempotency key. Logs should show the request ID and policy decision, then redact the response body. In Node.js, redaction belongs at the logger boundary as well as in middleware; a later console.error should not become a credential exfiltration path.
If the browser closes before acknowledgement, do not silently mint a second key. Mark the attempt unresolved, require an authenticated restart, and make rotation the recovery action. That preserves auditability: an operator can explain why a credential exists, who requested it, and which budget check preceded issuance.
Unattended workers have no trustworthy person to receive plaintext. A broker can authorize a workload with a short-lived identity, fetch the tenant secret from a vault, and inject it into the process without placing it in application logs. The workload gets access only while its policy and spend ceiling remain valid.
This model costs more moving parts: identity bootstrap, lease renewal, revocation, and an audit pipeline that joins broker events to billing decisions. It is unsuitable when a small tenant needs a human-readable key immediately and the team cannot operate the identity service. In that case, stick with one-time delivery and make rotation and support procedures explicit.
The inverse limitation matters too. One-time delivery is a poor fit for batch workers that restart without an operator. A vault is a better fit there, even if its operational overhead is higher.
A practical retention and access ledger
| Record | Keep | Purpose |
|---|---|---|
| Issuance decision | 90 days or policy window | Explain budget authorization |
| Credential fingerprint | Credential lifetime | Detect reuse without plaintext |
| Detailed request metadata | 14 days | Debug signup flow |
| Payload and authorization header | Zero days | Prevent secret retention |
Separate access logs from billing metrics. A metric such as credential_issue_total{result="allow"} is cheap to aggregate, while a per-tenant free-form label can become an index bill. Alert on unusual issuance rate, repeated unresolved handoffs, and spend decisions near the cap. Keep the alert payload small enough that the alert itself cannot leak a token.
I initially wanted every trace retained for 90 days. The retention calculation changed my mind: the extra bytes did not improve an auditor's answer once the decision ledger and immutable access log were complete. What you stop keeping is part of the control, and it also means accepting that some low-level debugging detail will be gone after the short window.
Choose one-time delivery for an interactive signup with a verified administrator, an explicit acknowledgement, and a documented rotation path. Choose vault retrieval for unattended workloads, frequent rotation, or strict separation between operators and runtime secrets. Whichever boundary you choose, enforce the workload spend cap before issuance, record policy evidence without plaintext, and test redaction with a deliberately invalid token such as sk_test_000000 so the test cannot grant access.
Top comments (0)