In a custom endpoint, call getAuthContext(request, env) to inspect the caller's verified sign-in context. It returns null when there is no usable sign-in token. If verification is temporarily unavailable, it can throw; do not treat that error as permission to continue.
Read the fields you actually need
The context can include userId, platformUserId, billingUserId, teamId, email, name, roles, permissions and session information. Do not assume these IDs are interchangeable. In particular, the app-user identity used for data ownership is not necessarily the platform-account identity used for a connected integration.
The email is normalized to lowercase when present and can be null. Roles can be empty, and legacy tokens can have different defaults. Screenshot and preview contexts can also use test identities. Avoid treating every ID as a number or assuming every caller is a member or admin.
Enforce the rule on the server
Require a usable auth context, then check the role or entitlement the operation needs. A browser field containing an email or role is not proof of identity. Use the purchase-check helper for paid access rather than guessing from an ID or email.
For debugging, return only the current caller's necessary information from an authenticated endpoint, and remove unnecessary diagnostics afterwards. Do not create a public endpoint that lists other users' auth contexts.