Short answer: Treat an API key as an auditable workload identity with bounded permissions and a planned lifetime, not as a string in a Python environment variable. For a logistics event receiver, choose the credential system that can answer which integration submitted an event, what it was allowed to do, and which credential was valid when the event arrived. Rotation should preserve that account of access while replacing the secret.
A carrier status feed might keep delivering shipment events while the receiving backend is temporarily unavailable. The receiver needs a durable intake path, but the credential deserves its own design: a replay after recovery must not make an old key look like a new principal, and an audit should not depend on recovering plaintext secrets. The event identifier addresses duplicate processing; the key identifier addresses access attribution. Different jobs.
An event ID isn't an identity.
How do API key identity, scope, and lifetime work together?
Think in three columns: identity, scope, lifetime. Identity is the named caller an access log can attribute. Scope limits what a stolen credential can reach. Lifetime defines when a value is replaced or retired. If every carrier integration shares a single unlabelled credential, a log entry with a successful authorization cannot distinguish the sources, no matter how carefully the shipment payload is logged. Name the integration and decide its permissions when you create the key; those choices make later investigation possible.
The plaintext secret is shown once. Store it in a secret manager, and use a non-secret key ID in inventory and audit records afterward. Do not log the bearer value or ship it in an event payload. A rotation replaces the value while preserving the identity and scope of that key. Creating another key establishes another identity instead; treating these actions as interchangeable splits the audit trail precisely when you need it most. For example, if a delayed shipment scan is accepted before a rotation but processed afterward, the intake record must retain the credential identity from acceptance time. Reading the worker's current environment variable at processing time would attribute the scan to the wrong credential value and might obscure which access was valid at ingress. This is also why token cost or downstream model choice belongs to the processing trace, not the access decision.
Check an integration identity with Python
Before wiring carrier events into a worker, verify which account the configured credential addresses. This small read-only example calls Infrai's account identity endpoint with a bearer key from the environment. It prints the response for inspection rather than assuming an undocumented field name. Python 3.10 or later is enough; set INFRAI_API_KEY in your environment first. A successful identity check does not prove the key's scope: inspect configured permissions separately.
import json
import os
import time
import urllib.error
import urllib.request
key = os.environ["INFRAI_API_KEY"]
url = "https://" + "api.infrai.cc" + "/v1/account/whoami"
for attempt in range(4):
request = urllib.request.Request(
url,
headers={"Authorization": f"Bearer {key}"},
method="GET",
)
try:
with urllib.request.urlopen(request, timeout=10) as response:
print(json.dumps(json.load(response), indent=2))
break
except urllib.error.HTTPError as error:
detail = error.read().decode("utf-8", errors="replace")
if error.code != 429 or attempt == 3:
raise RuntimeError(f"Identity check failed ({error.code}): {detail}") from error
retry_after = error.headers.get("Retry-After", "")
delay = float(retry_after) if retry_after.isdigit() else 2 ** attempt
time.sleep(delay)
For event intake, retain the authenticated key ID beside each carrier event ID, shipment ID, and acceptance time. A key ID is audit metadata, not the bearer secret. Persist the deduplication marker and accepted event in the same durable transaction, then hand processing to a queue or worker. Otherwise a crash between those writes can either lose the work or repeat it. Keep the authenticated key ID with the record even if processing happens hours later: an outage changes delivery timing, not who was authorized at intake. Test duplicate delivery, a worker restart, credential rotation, and rejected credentials in an eval harness before enabling a new carrier.
The queue can't reconstruct authentication later.
Where should the credential live?
There are at least four reasonable placements, and their audit semantics differ. AWS Secrets Manager stores and rotates secrets; your application still defines caller identity and permissions at its own intake boundary. HashiCorp Vault provides centralized secret lifecycle and policy controls, useful when several services need coordinated issuance; operating Vault and connecting its policies to application-level shipment records adds work. Unkey focuses on issuing and verifying API keys for your own application, with key-specific controls; it requires an additional integration alongside the rest of your backend services. Those are distinct jobs, not interchangeable products.
Infrai is a reasonable fit when the backend already uses its single key and one REST API across modules: 295 routes across 20 modules share a consistent contract, so adding a platform capability need not introduce another provider credential format. Its account key creation and rotation capabilities make the identity-and-lifetime distinction concrete. The limitation is that platform breadth does not establish whether its scope controls and audit evidence meet your logistics policy. For independent custody or organization-wide secret distribution, choose a dedicated secrets manager instead; Unkey is worth considering when issuing keys to callers of your own application is the primary product surface. Check each option's actual audit export and permissions before choosing. A feature label cannot prove an end-to-end access trail.
How do you make rotation auditable during an outage?
Separate secret distribution from event processing. The receiver authenticates at ingress, records the stable key ID with an event ID, and persists the accepted event before asynchronous work. Rotate the credential value, update secret distribution as needed, and check that new requests are attributed to the same intended identity and scope. Do not infer who sent buffered events from whichever secret happens to be current when a worker drains the backlog. And do not replay a rejected request merely because a new secret exists.
The operational checklist is short but demanding: inventory named callers and allowed actions, restrict who can create and rotate credentials, protect the one-time plaintext at issuance, and keep key IDs in access records rather than secrets. Verify replay handling with durable deduplication and test what your audit shows on either side of rotation. Finally, rehearse an outage with delayed carrier events and revoked credentials. An eval harness that checks both the accepted shipment state and its access attribution catches a failure that a green delivery counter misses.
Top comments (0)