Authentication

Developer (Studio) accounts

1. Register. POST /api/auth/register with email and password. A malformed address returns Enter a valid email; a short password returns Password must be at least 6 characters; a taken address returns An account with this email already exists.
2. Verify the address. POST /api/auth/send-verification then POST /api/auth/verify-email-otp. The code is six digits and expires in ten minutes; Code expired. Please request a new one. and Invalid verification code are the two refusals.
3. Sign in. POST /api/auth/login. Wrong credentials answer Email or password is incorrect — deliberately the same message for both halves.
4. Keep the token. The response carries a JWT whose payload is { uid, email, source: "appsinity_studio" }. Studio stores it as appsinity_studio_token.
5. Send it on every call. Authorization: Bearer <token>. Nothing else identifies you.

POST /api/auth/login
{ "email": "[email protected]", "password": "..." }

200 { "token": "eyJhbGciOi...", "user": { "uid": "...", "email": "..." } }

GET /api/auth/me
Authorization: Bearer eyJhbGciOi...

200 { uid, email, display_name, onboarding_complete, approval_status, ... }

Player accounts

The store front has its own account family under /api/user-auth/*: register, login, me, profile, send-verification, verify-email-otp and username-available. Passwords are hashed with bcrypt at cost twelve, and the same minimum length applies.

Every auth failure you will see

Optional verification on writes

Traffic and play events accept a token but do not need one. The handler attempts verification, takes the uid if the signature checks out, and records the event either way. For your own instrumentation that means an unauthenticated call is a valid call — and one that a player cannot be blamed for.

POST /api/listing-traffic
Authorization: <ignored if absent>
{ "collection": "games", "listingId": "my-game", "eventType": "visit",
  "source": "search", "country": "IN" }

200 -> the event row is written with uid = "" when no token was supplied

Keeping a session safe

• There is no two-factor option on either account family, so the password and the mailbox are the whole defense.
• Logout clears the stored token; there is no server-side revocation list, so a token you have already handed to a browser extension stays valid for its remaining thirty days.
• Never put a token in a URL, a log line or a screenshot of a support conversation.
• Do not run the token in CI. Without keys or scoped credentials, automation inherits your full account rights, see API keys.
• One password per account; a Studio password reused elsewhere is a breach of your store account waiting to happen.