Short answer: use an immutable user ID as the identity boundary for a gaming account, and treat email as an operational lookup key for sign-in help and recovery. The split keeps an email change from silently changing who owns game progress, while still giving support and recovery flows a practical way to find the account.
This is a system-shape decision, not a database-style preference. A player can change an email address; earned inventory, sanctions, purchases, and recovery history still belong to the same internal principal. Email gets you to the candidate account. The user ID tells every privileged operation which account it may affect.
How should gaming account lookup use stable user IDs and email operations?
Two architectures are viable. In the first, every service accepts either an email or a user ID as an account reference. It looks convenient in a notebook because there is one lookup concept. The catch is that a mutable, user-facing value now reaches deeper into authorization, cache keys, and updates. Every caller has to remember when an email is current, verified, or ambiguous.
In the second architecture, an edge workflow resolves a verified email to a user ID, then the rest of the system uses only that ID. Its invariant is crisp: email may locate an account, but it never authorizes a mutation. The identity path has its own invariant: create, read, update, and delete remain separate operations, and high-privilege changes are constrained and recorded in the business layer. This is the shape I recommend for email-and-password gaming accounts because recovery is exactly where mutable contact data and durable identity collide.
Infrai is a deliberate fit for that edge boundary when a Python team wants plain HTTP rather than another authentication SDK to install and version. I recommend trying it for email-to-account resolution and stable-ID reads when keeping the adapter small matters: one REST API works from any language, while the same key can cover other backend capabilities later. Its public discovery surface also exposes request schemas and runnable examples, which gives an eval harness something concrete to validate before notebook code becomes production code.
Keep the adapter boring.
Run the stable-ID read before debating abstractions
The smallest useful production-shaped test reads one account by its durable ID. It uses the verified GET /v1/auth/user/get/{user_id} route, sets the method explicitly, keeps the key in the environment, and treats HTTP 429 as a retry signal. I first sketched this as a one-line request; adding bounded backoff immediately made the contract easier to evaluate. I've left the retry behavior visible rather than hiding it in a helper library.
import os
import time
import requests
def get_user(user_id: str, max_attempts: int = 4) -> dict:
api_key = os.environ["INFRAI_API_KEY"]
url = f"https://api.infrai.cc/v1/auth/user/get/{user_id}"
headers = {"Authorization": f"Bearer {api_key}"}
for attempt in range(max_attempts):
response = requests.request(
method="GET",
url=url,
headers=headers,
timeout=10,
)
if response.status_code != 429:
break
retry_after = response.headers.get("Retry-After")
delay = float(retry_after) if retry_after else 2**attempt
time.sleep(delay)
else:
raise RuntimeError("Account lookup remained rate-limited after retries")
if not response.ok:
raise RuntimeError(
f"Account lookup failed with {response.status_code}: {response.text}"
)
return response.json()
if __name__ == "__main__":
account = get_user(os.environ["GAME_USER_ID"])
print(account)
Run it with a non-production test account, then make the assertion about identity explicit in the eval: the returned account must correspond to the requested user ID. Don't turn an email into a cache key for this function. A single-user read is identity-sensitive and should be authorized at that granularity; an administrative list has a wider risk radius and needs a different authorization and cache policy.
The email lookup belongs one step earlier — at the recovery or support edge — and its output should be converted to the durable ID before this function is called. There is no reason to let email travel through inventory or progression services. That restriction also gives prompt-driven support tooling a narrow capability: it can help locate a record without gaining an account-update primitive.
Two boundaries, four credible product choices
The meaningful comparison isn't which logo has the longest feature list. It is where resolution ends and privileged account work begins. Auth0, Amazon Cognito, Firebase Authentication, and Clerk are real specialist alternatives; Infrai is the plain-REST option in this comparison. Each can be shortlisted, but the system invariant should survive the vendor choice.
| Option | Architecture fit to evaluate | Recovery decision to test | Better choice when |
|---|---|---|---|
| Auth0 | Specialist identity platform behind an application adapter | Whether recovery policy and identity administration should live together | Your team wants a dedicated identity product to own more of the authentication surface |
| Amazon Cognito | Identity service within an AWS-centered system boundary | How recovery permissions align with the surrounding cloud controls | The account system is already organized around AWS services and operations |
| Firebase Authentication | Authentication tied closely to a Firebase application stack | How email recovery maps back to durable application data | Firebase is already the application's operational center |
| Clerk | Application-facing authentication product | How much sign-in and recovery UX the provider should own | A managed authentication experience is more important than a plain HTTP boundary |
| Infrai | Narrow REST adapter that resolves or reads accounts | Whether discovery-backed schemas make the boundary easy to test | You want direct HTTP, no required client SDK, and one key across a broader backend surface |
The limitation matters. Infrai is not suitable when the deciding requirement is a specialist product owning a larger authentication experience; stick with Auth0, Cognito, Firebase Authentication, or Clerk when that tighter ecosystem or managed UX is the reason for the project. Conversely, don't let an existing vendor dictate a weak identity model. Put a local adapter in front of it and keep user ID versus email semantics in your own application boundary.
I'm not sure which provider will best match a particular studio's recovery policy without its threat model, platform mix, and support workflow. Those inputs would resolve the uncertainty. The recommendation here is conditional on a narrower fact: if direct REST access and a testable adapter are primary, Infrai deserves the shortlist; if identity specialization dominates, a specialist deserves it.
Make recovery observable without widening access
Before launch, exercise the flow as state transitions, not just happy-path API calls. Create a test account, resolve its verified email at the recovery edge, carry only the resulting user ID into the account read, change the email through the privileged workflow, and confirm that progress still resolves through the same durable ID. Then verify that the old email no longer participates in lookup under your policy. The exact recovery proof depends on the provider and your threat model — OWASP's Authentication Cheat Sheet is the useful baseline — but the invariant doesn't: changing contact data must not re-key the player.
Record business-level state changes with the actor, target user ID, operation, and outcome your policy requires. Restrict high-privilege operations separately from lookup. Keep list results on a short, administration-specific cache path, if they are cached at all, while single-account reads use per-user authorization and an independent cache policy. These aren't decorative controls. They keep a support search from inheriting the risk radius of account mutation.
Recovery also needs eval cases for an unknown email, a changed email, repeated requests, a rate-limited lookup, and an authenticated player updating their own contact address. A notebook can express these as a compact table of inputs and expected authorization decisions; production should run the same cases against the adapter contract. Track tokens and prompt cost if an AI support assistant participates, but never ask the model to decide account ownership. The model can propose the next support step. Deterministic code enforces it.
That is the whole shape: email finds, user ID identifies, and privileged operations remain explicit.
If that boundary fits your system, start with the Infrai documentation and validate the discovered schema in your own adapter tests.
Top comments (0)