In-game login (PC)

This page is the PC login flow (steps 1–6).

Token exchange (steps 4–5) is not your game server. The game client calls pc-auth-bridge; the bridge then POSTs to Fetamix. Hosts and paths: PC auth bridge (client).

Fetamix API base path: `/api/v1` — `login-session`, Google OAuth, `GET /game/auth/verify` stay here.

Step 1 `login-session` (client-generated PKCE): required `client_veri_enc`, `client_verifier`, `client_secret`, `pc_oauth_state`. Follow the request body example and the field table (Swagger).

Open PC auth bridge (client) — hosts, GET /getrefreshToken, refresh

API base URL

Live

https://api.fetamix.com/api/v1

Sandbox

https://api-sandbox.fetamix.com/api/v1

Fetamix endpoints (called by your code)

Fetamix base URL matches the REST overview. Token exchange only uses the pc-auth-bridge host, not `api.fetamix.com`.

Who calls what
Game client → Fetamix: `login-session`, Google OAuth in the system browser, `GET /game/auth/verify`. `refresh` may hit Fetamix or the bridge.
Game client → pc-auth-bridge: token exchange. Do not send this hop to your game server. See PC auth bridge (client).
pc-auth-bridge → Fetamix: `access-and-refresh-tokens`. Do not POST this Fetamix URL from the game client or a studio game server.

`login-session` body
`client_veri_enc`, `client_verifier`, `client_secret`, `pc_oauth_state` — see step 1 and Swagger.

Steps 4–5
The client sends `one_time_token`, `client_veri_enc`, `fingerprint`, `fingerprint_method` to pc-auth-bridge.
The bridge POSTs the same JSON to Fetamix and returns `token` / `refresh_token`.

Caller	Method	Path	Purpose
Game client	POST	/game/pc/auth/login-session	Purpose Register PKCE, secrets, and OAuth state; receive `google_oauth_start_url`. JSON body `client_veri_enc` · `client_verifier` · `client_secret` · `pc_oauth_state`
PC auth bridge	POST	/game/pc/auth/access-and-refresh-tokens	Purpose Exchange `one_time_token` for an in-game access JWT (response field `token`) and `refresh_token`. Who calls this Fetamix URL pc-auth-bridge — not the game client, not your game server. JSON body `one_time_token` · `client_veri_enc` · `fingerprint` (SHA-256 → 64 lowercase hex) · `fingerprint_method` (e.g. S256) Notes Do not send `client_verifier` here — only on `login-session`. Steps 4–5: client → pc-auth-bridge (same four fields) → bridge POSTs the same JSON here.
Game client	POST	/game/pc/auth/refresh	Purpose Refresh (no rotation) — new access `token` (JWT). Response `refresh_token` echoes the same value you sent; the server only extends DB expiry (1-year sliding policy). JSON body `refresh_token` · `client_veri_enc` · `fingerprint` · `fingerprint_method` (e.g. S256) The Unity sample sends this through pc-auth-bridge. Direct Fetamix POST is also valid.
Game client	GET	/game/auth/verify	Purpose Check whether the stored in-game access JWT is still valid. Request No body. `Authorization: Bearer <JWT>` — the `token` from `access-and-refresh-tokens` or `refresh` (one space after `Bearer`). Optional `?key=` — if it matches the JWT’s `device_key`, adds device check (on PC, often the same `fingerprint` as login/refresh). Result 200 — `success`, `data` (`valid`, `sub`, `type`, `game_id`, …) 401 — expired, bad signature, DB/`key` mismatch, suspended account, … Tip — Call once before using a saved JWT (e.g. after app start). On failure, use `refresh` or restart from `login-session`.

Integration steps and API details (1–6)

Right below each step’s narrative you’ll find the matching HTTP spec (endpoint card).

The server does not open a browser for you. After step 1’s JSON response, the client must open the step 2 `google_oauth_start_url`.

Steps 4–5 token exchange go through pc-auth-bridge, not a studio game server.

Step 1

Call `POST /game/pc/auth/login-session` to register the session. You only get JSON; the browser does not open by itself.

POST /game/pc/auth/login-session

Game client

The client generates a PKCE pair (code_verifier → code_challenge), then calls this endpoint with an HTTPS JSON body.

Body fields
`client_veri_enc` — PKCE code_challenge
`client_verifier` — PKCE code_verifier (plaintext)
`client_secret` · `pc_oauth_state`

Send `client_verifier` only here. The server keeps it until the Google token exchange.
Do not put `client_verifier` in later JSON bodies (e.g. `access-and-refresh-tokens`).

Live

https://api.fetamix.com/api/v1/game/pc/auth/login-session

Sandbox

https://api-sandbox.fetamix.com/api/v1/game/pc/auth/login-session

JSON body fields

Name	Required	Description
client_veri_enc	Yes	PKCE code_challenge, Base64URL(SHA256(verifier)) — client-generated
client_verifier	Yes	PKCE code_verifier (plaintext). Send only on login-session; not on access-and-refresh-tokens
client_secret	Yes	Console-issued game secret — server resolves game_id
pc_oauth_state	Yes	Unpredictable opaque nonce. Must differ from `client_veri_enc` (PKCE code_challenge).

Example request body

{
  "client_veri_enc": "BASE64URL(SHA256(code_verifier))",
  "client_verifier": "<PKCE code_verifier (plaintext)>",
  "client_secret": "<console-issued game client_secret>",
  "pc_oauth_state": "<opaque nonce, must differ from client_veri_enc>"
}

Response — example success body

{
  "success": true,
  "session_id": "hex…",
  "expires_in": 600,
  "google_oauth_start_url": "https://api…/api/v1/game/pc/auth/google-oauth?session_id=…"
}

Response fields

Name	Required	Description
success	Yes	true
session_id	Yes	Opaque login session id; it appears inside `google_oauth_start_url`. Open that full URL in the browser without editing it.
expires_in	Yes	Session / URL validity in seconds (~10 min)
google_oauth_start_url	Yes	What it is The Fetamix API entry URL for the system browser. Shape: `GET /game/pc/auth/google-oauth?session_id=…` — open the full string as returned. Do not Do not hand-build or open Google’s OAuth sign-in URL first. Flow When the browser hits this URL, the server 302s to Google’s OAuth sign-in step (after one hop through Fetamix). On PC Avoid in-app WebView—Google often blocks or delivers an incomplete OAuth flow there.

Diagrams may omit these fields: they are HTTP conveniences (opaque session key and ready-made URL) on top of the same flow.

Step 2

Open the full `google_oauth_start_url` from the previous step in the system browser (e.g. `Application.OpenURL`).

Avoid in-app WebView—Google often does not complete OAuth or deliver data there on PC.

This is not a separate “call GET from your HTTP client” step.

Leave `session_id` in the URL as returned.

`google_oauth_start_url` — open this URL in the system browser

Browser

Do not implement this as “call GET from the game client.”

Pass the full `google_oauth_start_url` from login-session to the system browser (e.g. `Application.OpenURL`).

Do not use an in-app WebView for Google sign-in on PC—Google often withholds or blocks the OAuth flow inside embedded WebViews.

Further redirects are handled by that external browser (Fetamix API once, then Google).

Open exactly the `google_oauth_start_url` string from step 1 in the system browser (e.g. `Application.OpenURL`).

Do not use an in-app WebView for this Google OAuth step on PC—Google often blocks or fails to return data there.

The lines below show only the URL shape; do not hand-build or edit it.

Livehttps://api.fetamix.com/api/v1/game/pc/auth/google-oauth?session_id=…

Sandboxhttps://api-sandbox.fetamix.com/api/v1/game/pc/auth/google-oauth?session_id=…

The host (live vs sandbox) is already correct in the step 1 response for the API you used.

Part of the opened URL (reference only)

Name	Required	Description
session_id	Yes	Already part of `google_oauth_start_url` — use the URL as returned; do not hand-build or edit the query

Roughly what happens on the wire when that URL loads (reference)

HTTP/1.1 302 Found
Location: https://accounts.google.com/o/oauth2/v2/auth?client_id=…&redirect_uri=…&state=…&code_challenge=…

Browser navigation (reference — do not parse in game code)

Name	Required	Description
HTTP status	Yes	Often 302 when the browser hits the Fetamix API — not a response your game parses
Location	Yes	Next URL the browser follows (e.g. Google OAuth sign-in)

Summary: open `google_oauth_start_url` in the system browser—not an in-app WebView for PC Google OAuth.

Invalid or expired session may show 400 JSON in the browser instead of a redirect.

Step 3

When Google sign-in finishes, the Fetamix server issues a one-time `one_time_token` string and hands it to the browser.

The game client does not call another Fetamix REST endpoint here.

You only need to get that string into the app.

PKCE: Outside the native client (browser address bar, Google redirects), only the code_challenge is in play. The code_verifier never appears on this leg—it is sent to Fetamix only in step ① `login-session` as HTTPS JSON.

Below is a typical local loopback redirect flow to bring `one_time_token` into the game client. Implement the same idea in your stack—e.g. a short-lived local HTTP listener or embedded web server.

Local loopback

To receive `one_time_token` via HTTP 302 to localhost, add the optional `oauth_loopback_redirect_uri` field to `login-session` (see Swagger for format and rules). The game client listens on that local URL (e.g. `http://127.0.0.1:{port}/…`) for a short window.

After Google sign-in the browser is redirected (HTTP 302) there with `one_time_token=…` in the query. Parse it from the first request’s query string.

The excerpt below is a loopback-oriented `login-session` body (`client_verifier` and `oauth_loopback_redirect_uri`). The four required fields match step 1.

Reference (request body and what you receive)

// 1) POST login-session body (excerpt)
{
  "client_veri_enc": "...",
  "client_verifier": "...",
  "client_secret": "...",
  "pc_oauth_state": "...",
  "oauth_loopback_redirect_uri": "http://127.0.0.1:3847/callback"
}

2) Example request line the browser may hit after redirect (your local listener receives it — parse one_time_token from the query)
GET http://127.0.0.1:3847/callback?one_time_token=***

Other approaches may fit your client or policy—for example letting the user copy the `one_time_token` from the callback HTML into the game. This doc focuses on the loopback flow above.

There is no extra Fetamix REST URL to call in this step—only bring `one_time_token` into the game client.

Step 4

The game client does not call Fetamix here; it sends ClientVeriEnc, the one-time token, Fingerprint (SHA-256 digest as 64 lowercase hex), and fingerprint_method (e.g. `S256`) to pc-auth-bridge. Do not send this hop to a studio game server.

Hosts: Live `https://pab.fetamix.com`, Sandbox `https://pab-sandbox.fetamix.com`. Unity sample: `GET /getrefreshToken`. Full paths: PC auth bridge (client).

On PC it cannot be made perfectly unexfiltratable; still do not write it to logs, config, disk, or debug output—keep it transient in memory as much as your flow allows.

Example fingerprint input: machine GUID, CPU serial, and motherboard serial concatenated per spec, UTF-8–normalized, then SHA-256.

Game client → pc-auth-bridge

Step 4

Send ClientVeriEnc, `one_time_token`, Fingerprint, fingerprint_method (e.g. S256) to pc-auth-bridge — not your game server, not `api.fetamix.com`.

Hosts: Live `https://pab.fetamix.com` · Sandbox `https://pab-sandbox.fetamix.com`.

Unity sample: `GET /getrefreshToken`. New clients may POST the same four fields. Full paths: PC auth bridge (client).

Fingerprint is computed per spec from machine identifiers (UTF-8, SHA-256) and passed as `fingerprint` / `fingerprint_method`.

{ "client_veri_enc": "…", "one_time_token": "…", "fingerprint": "64-char lowercase hex (SHA-256 digest)", "fingerprint_method": "S256" }

Open PC auth bridge (client) — hosts, GET /getrefreshToken, refresh

Step 5

Step 5: pc-auth-bridge POSTs the same four fields to Fetamix `POST /game/pc/auth/access-and-refresh-tokens`, then returns `token` (in-game access JWT) and `refresh_token` to the client.

The game client must not hit this Fetamix URL. The card below is the Fetamix spec the bridge calls.

Keep `fingerprint` and the other fields consistent on exchange and later refresh.

POST /game/pc/auth/access-and-refresh-tokens

PC auth bridge

This Fetamix URL is called by pc-auth-bridge. Do not POST it from the game client or a studio game server. In step 4 the client sends the four fields to the bridge (`GET|POST /getrefreshToken` or the same path on the bridge host).

The bridge POSTs `one_time_token`, `client_veri_enc` (same PKCE code_challenge as login-session), `fingerprint`, and `fingerprint_method`. Fetamix validates the one-time token and PKCE, then returns an in-game access JWT (`token`) and `refresh_token`. The bridge forwards that JSON to the client.

The plaintext PKCE verifier was sent only on login-session; it is not in this body.

Live

https://api.fetamix.com/api/v1/game/pc/auth/access-and-refresh-tokens

Sandbox

https://api-sandbox.fetamix.com/api/v1/game/pc/auth/access-and-refresh-tokens

JSON body fields

Name	Required	Description
one_time_token	Yes	One-time token from the browser flow
client_veri_enc	Yes	Same PKCE code_challenge as login-session; must match the pending record
fingerprint	Yes	SHA-256 digest encoded as 64 lowercase hex characters (other hashes would be a different length). Example (our design): concatenate machine GUID, CPU serial, and motherboard serial per spec, UTF-8–normalize, then SHA-256. Whatever string the client builds and sends, if the fingerprint matches the first value on later calls (e.g. `/refresh`), the server treats it as the same client.
fingerprint_method	Yes	Same convention as step 4 (bridge handoff); use S256

Example request body

{
  "one_time_token": "…",
  "client_veri_enc": "same PKCE code_challenge as at login-session (client-generated)",
  "fingerprint": "64-char lowercase hex SHA-256",
  "fingerprint_method": "S256"
}

Response — example success body

{
  "success": true,
  "token": "<in-game access JWT>",
  "user": {
    "id": 1,
    "email": "user@example.com",
    "nick_name": "…",
    "profile_image": "https://…"
  },
  "refresh_token": "…"
}

Response fields

Name	Required	Description
success	Yes	true
token	Yes	In-game access token (JWT). JSON field name: token
user	Yes	id, email, nick_name, profile_image
refresh_token	Yes	Always present on success; fingerprint etc. are not echoed (caller already has them)

The server does not validate the meaning of the pre-hash input; matching fingerprint hex across issue and later requests means the same client.

Non-production responses may include extra fields such as pending_storage.

Step 6

Keep AT in memory (or similar) and RT in a vault (e.g. Windows Credential Locker).

Use the APIs below for refresh and verification afterward.

POST /game/pc/auth/refresh

Game client

Issues a new in-game access JWT using the stored refresh token. The refresh token is not rotated (response echoes the same value); only DB expiry is extended on a sliding window (1-year policy). Send client_veri_enc, fingerprint, and fingerprint_method in the JSON body.

Live

https://api.fetamix.com/api/v1/game/pc/auth/refresh

Sandbox

https://api-sandbox.fetamix.com/api/v1/game/pc/auth/refresh

JSON body fields

Name	Required	Description
refresh_token	Yes	Stored refresh token from prior response
client_veri_enc	Yes	Same PKCE code_challenge the client sent at login-session; must match stored value (required in body).
fingerprint	Yes	SHA-256: 64 lowercase hex chars; must match the fingerprint from ①; a match means the same client.
fingerprint_method	Yes	Same convention as at issue; use S256

Example request body

{
  "refresh_token": "…",
  "client_veri_enc": "same PKCE code_challenge as at login-session",
  "fingerprint": "64-char lowercase hex (SHA-256 digest)",
  "fingerprint_method": "S256"
}

Response — example success body

{
  "success": true,
  "token": "<in-game access JWT>",
  "refresh_token": "…",
  "user": {
    "id": 1,
    "email": "user@example.com",
    "nick_name": "…",
    "profile_image": "https://…"
  }
}

Response fields

Name	Required	Description
success	Yes	true
token	Yes	New in-game access token (JWT). JSON field name: token
refresh_token	Yes	Same as the refresh_token sent in the request (no rotation). Clients may keep the stored value
user	Yes	id, email, nick_name, profile_image

On failure: HTTP 401 and error_code. On success the refresh row keeps the same hash; only expires_at is extended.

GET /game/auth/verify

Game client

Validates the in-game access token (JWT) via Authorization: Bearer. Same endpoint as the standard in-game login doc.

Live

https://api.fetamix.com/api/v1/game/auth/verify?

Sandbox

https://api-sandbox.fetamix.com/api/v1/game/auth/verify?

Headers

Name	Required	Description
Authorization	Yes	Bearer {in-game access JWT}

Query parameters

Name	Required	Description
key	No	Optional query param per server validation policy

Response — example success body

{
  "success": true,
  "data": {
    "valid": true,
    "sub": 1,
    "type": "app",
    "game_id": 1,
    "iat": 1761714925,
    "exp": 4825056125
  }
}

Response fields

Name	Required	Description
success	Yes	true
data.valid	Yes	true
data.sub	Yes	User id
data.type	Yes	e.g. app
data.game_id	Yes	Game id
data.device_key	No	May be present depending on server implementation
data.iat	Yes	Issued-at (unix)
data.exp	Yes	Expiry (unix)

Samples by integration step

Excerpts aligned with steps 1–6 on this page.
Unity paths refer to `unity_pc_sample` / `Assets/Scripts/Auth`.
Step 4 calls pc-auth-bridge. Step 5 is the JSON the bridge returns (it POSTs Fetamix for you).
Adjust types, timeouts, and error handling for production.

Step 1 — POST /game/pc/auth/login-session (client)

var body = PcAuthJsonHelpers.BuildLoginSessionBody(
    clientVeriEnc,
    clientVerifier,
    clientSecret,
    pcOauthState,
    oauthLoopbackRedirectUriOrNull);

var url = $"{apiBaseUrl.TrimEnd('/')}/game/pc/auth/login-session";
using var req = new UnityWebRequest(url, "POST");
req.uploadHandler = new UploadHandlerRaw(Encoding.UTF8.GetBytes(body));
req.downloadHandler = new DownloadHandlerBuffer();
req.SetRequestHeader("Content-Type", "application/json");
yield return req.SendWebRequest();

Step 2 — Open google_oauth_start_url in the system browser

Application.OpenURL(googleOauthStartUrlFromLoginSession);

Step 3 — Receive one_time_token (loopback example)

using var loop = PcOAuthLoopbackReceiver.TryCreate(out var loopErr);
if (loop == null) { yield break; }

while (!loop.IsComplete) yield return null;
var oneTimeToken = loop.OneTimeToken;

Step 4 — Client → pc-auth-bridge (four fields)

yield return PcGameServerAuthClient.GetRefreshTokenCoroutine(
    gameServerBaseUrl, // pc-auth-bridge, e.g. https://pab.fetamix.com
    oneTimeToken,
    clientVeriEnc,
    fingerprintHex,
    onSuccessBody: json => { },
    onError: err => { });

Step 5 — Tokens the bridge returns (after it POSTs Fetamix)

// Game client does not POST Fetamix access-and-refresh-tokens.
// pc-auth-bridge does that hop and returns the same JSON:

{
  "success": true,
  "token": "<in-game access JWT>",
  "refresh_token": "…"
}

Step 6 — Client: refresh (no rotation) & JWT verify

6a — POST /game/pc/auth/refresh

var fp = PcDeviceFingerprint.ComputeSha256HexLower();
var body = PcAuthJsonHelpers.BuildRefreshBody(
    refreshToken, fp, "S256", clientVeriEnc);
// Unity sample uses pc-auth-bridge (gameServerBaseUrl). Fetamix apiBaseUrl also works.
var url = $"{gameServerBaseUrl.TrimEnd('/')}/game/pc/auth/refresh";
using var req = new UnityWebRequest(url, "POST");
req.uploadHandler = new UploadHandlerRaw(Encoding.UTF8.GetBytes(body));
req.downloadHandler = new DownloadHandlerBuffer();
req.SetRequestHeader("Content-Type", "application/json");
yield return req.SendWebRequest();

6b — GET /game/auth/verify

using var verifyReq = UnityWebRequest.Get($"{apiBaseUrl.TrimEnd('/')}/game/auth/verify");
verifyReq.SetRequestHeader("Authorization", "Bearer " + accessJwt);
verifyReq.downloadHandler = new DownloadHandlerBuffer();
yield return verifyReq.SendWebRequest();

In-game login (PC)

Open PC auth bridge (client) — hosts, GET /getrefreshToken, refresh

API base URL

Live

https://api.fetamix.com/api/v1

Sandbox

https://api-sandbox.fetamix.com/api/v1

Fetamix endpoints (called by your code)

Caller	Method	Path	Purpose
Game client	POST	/game/pc/auth/login-session	Purpose Register PKCE, secrets, and OAuth state; receive `google_oauth_start_url`. JSON body `client_veri_enc` · `client_verifier` · `client_secret` · `pc_oauth_state`
PC auth bridge	POST	/game/pc/auth/access-and-refresh-tokens	Purpose Exchange `one_time_token` for an in-game access JWT (response field `token`) and `refresh_token`. Who calls this Fetamix URL pc-auth-bridge — not the game client, not your game server. JSON body `one_time_token` · `client_veri_enc` · `fingerprint` (SHA-256 → 64 lowercase hex) · `fingerprint_method` (e.g. S256) Notes Do not send `client_verifier` here — only on `login-session`. Steps 4–5: client → pc-auth-bridge (same four fields) → bridge POSTs the same JSON here.
Game client	POST	/game/pc/auth/refresh	Purpose Refresh (no rotation) — new access `token` (JWT). Response `refresh_token` echoes the same value you sent; the server only extends DB expiry (1-year sliding policy). JSON body `refresh_token` · `client_veri_enc` · `fingerprint` · `fingerprint_method` (e.g. S256) The Unity sample sends this through pc-auth-bridge. Direct Fetamix POST is also valid.
Game client	GET	/game/auth/verify	Purpose Check whether the stored in-game access JWT is still valid. Request No body. `Authorization: Bearer <JWT>` — the `token` from `access-and-refresh-tokens` or `refresh` (one space after `Bearer`). Optional `?key=` — if it matches the JWT’s `device_key`, adds device check (on PC, often the same `fingerprint` as login/refresh). Result 200 — `success`, `data` (`valid`, `sub`, `type`, `game_id`, …) 401 — expired, bad signature, DB/`key` mismatch, suspended account, … Tip — Call once before using a saved JWT (e.g. after app start). On failure, use `refresh` or restart from `login-session`.

Integration steps and API details (1–6)

Step 1

Call `POST /game/pc/auth/login-session` to register the session. You only get JSON; the browser does not open by itself.

POST /game/pc/auth/login-session

Game client

Live

https://api.fetamix.com/api/v1/game/pc/auth/login-session

Sandbox

https://api-sandbox.fetamix.com/api/v1/game/pc/auth/login-session

JSON body fields

Name	Required	Description
client_veri_enc	Yes	PKCE code_challenge, Base64URL(SHA256(verifier)) — client-generated
client_verifier	Yes	PKCE code_verifier (plaintext). Send only on login-session; not on access-and-refresh-tokens
client_secret	Yes	Console-issued game secret — server resolves game_id
pc_oauth_state	Yes	Unpredictable opaque nonce. Must differ from `client_veri_enc` (PKCE code_challenge).

Example request body

{
  "client_veri_enc": "BASE64URL(SHA256(code_verifier))",
  "client_verifier": "<PKCE code_verifier (plaintext)>",
  "client_secret": "<console-issued game client_secret>",
  "pc_oauth_state": "<opaque nonce, must differ from client_veri_enc>"
}

Response — example success body

{
  "success": true,
  "session_id": "hex…",
  "expires_in": 600,
  "google_oauth_start_url": "https://api…/api/v1/game/pc/auth/google-oauth?session_id=…"
}

Response fields

Name	Required	Description
success	Yes	true
session_id	Yes	Opaque login session id; it appears inside `google_oauth_start_url`. Open that full URL in the browser without editing it.
expires_in	Yes	Session / URL validity in seconds (~10 min)
google_oauth_start_url	Yes	What it is The Fetamix API entry URL for the system browser. Shape: `GET /game/pc/auth/google-oauth?session_id=…` — open the full string as returned. Do not Do not hand-build or open Google’s OAuth sign-in URL first. Flow When the browser hits this URL, the server 302s to Google’s OAuth sign-in step (after one hop through Fetamix). On PC Avoid in-app WebView—Google often blocks or delivers an incomplete OAuth flow there.

Diagrams may omit these fields: they are HTTP conveniences (opaque session key and ready-made URL) on top of the same flow.

Step 2

`google_oauth_start_url` — open this URL in the system browser

Browser

Livehttps://api.fetamix.com/api/v1/game/pc/auth/google-oauth?session_id=…

Sandboxhttps://api-sandbox.fetamix.com/api/v1/game/pc/auth/google-oauth?session_id=…

The host (live vs sandbox) is already correct in the step 1 response for the API you used.

Part of the opened URL (reference only)

Name	Required	Description
session_id	Yes	Already part of `google_oauth_start_url` — use the URL as returned; do not hand-build or edit the query

Roughly what happens on the wire when that URL loads (reference)

HTTP/1.1 302 Found
Location: https://accounts.google.com/o/oauth2/v2/auth?client_id=…&redirect_uri=…&state=…&code_challenge=…

Browser navigation (reference — do not parse in game code)

Name	Required	Description
HTTP status	Yes	Often 302 when the browser hits the Fetamix API — not a response your game parses
Location	Yes	Next URL the browser follows (e.g. Google OAuth sign-in)

Summary: open `google_oauth_start_url` in the system browser—not an in-app WebView for PC Google OAuth.

Invalid or expired session may show 400 JSON in the browser instead of a redirect.

Step 3

Local loopback

Reference (request body and what you receive)

// 1) POST login-session body (excerpt)
{
  "client_veri_enc": "...",
  "client_verifier": "...",
  "client_secret": "...",
  "pc_oauth_state": "...",
  "oauth_loopback_redirect_uri": "http://127.0.0.1:3847/callback"
}

2) Example request line the browser may hit after redirect (your local listener receives it — parse one_time_token from the query)
GET http://127.0.0.1:3847/callback?one_time_token=***

Other approaches may fit your client or policy—for example letting the user copy the `one_time_token` from the callback HTML into the game. This doc focuses on the loopback flow above.

There is no extra Fetamix REST URL to call in this step—only bring `one_time_token` into the game client.

Step 4

Game client → pc-auth-bridge

{ "client_veri_enc": "…", "one_time_token": "…", "fingerprint": "64-char lowercase hex (SHA-256 digest)", "fingerprint_method": "S256" }

Open PC auth bridge (client) — hosts, GET /getrefreshToken, refresh

Step 5

POST /game/pc/auth/access-and-refresh-tokens

PC auth bridge

Live

https://api.fetamix.com/api/v1/game/pc/auth/access-and-refresh-tokens

Sandbox

https://api-sandbox.fetamix.com/api/v1/game/pc/auth/access-and-refresh-tokens

JSON body fields

Name	Required	Description
one_time_token	Yes	One-time token from the browser flow
client_veri_enc	Yes	Same PKCE code_challenge as login-session; must match the pending record
fingerprint	Yes	SHA-256 digest encoded as 64 lowercase hex characters (other hashes would be a different length). Example (our design): concatenate machine GUID, CPU serial, and motherboard serial per spec, UTF-8–normalize, then SHA-256. Whatever string the client builds and sends, if the fingerprint matches the first value on later calls (e.g. `/refresh`), the server treats it as the same client.
fingerprint_method	Yes	Same convention as step 4 (bridge handoff); use S256

Example request body

{
  "one_time_token": "…",
  "client_veri_enc": "same PKCE code_challenge as at login-session (client-generated)",
  "fingerprint": "64-char lowercase hex SHA-256",
  "fingerprint_method": "S256"
}

Response — example success body

{
  "success": true,
  "token": "<in-game access JWT>",
  "user": {
    "id": 1,
    "email": "user@example.com",
    "nick_name": "…",
    "profile_image": "https://…"
  },
  "refresh_token": "…"
}

Response fields

Name	Required	Description
success	Yes	true
token	Yes	In-game access token (JWT). JSON field name: token
user	Yes	id, email, nick_name, profile_image
refresh_token	Yes	Always present on success; fingerprint etc. are not echoed (caller already has them)

The server does not validate the meaning of the pre-hash input; matching fingerprint hex across issue and later requests means the same client.

Non-production responses may include extra fields such as pending_storage.

Step 6

Keep AT in memory (or similar) and RT in a vault (e.g. Windows Credential Locker).

Use the APIs below for refresh and verification afterward.

POST /game/pc/auth/refresh

Game client

Live

https://api.fetamix.com/api/v1/game/pc/auth/refresh

Sandbox

https://api-sandbox.fetamix.com/api/v1/game/pc/auth/refresh

JSON body fields

Name	Required	Description
refresh_token	Yes	Stored refresh token from prior response
client_veri_enc	Yes	Same PKCE code_challenge the client sent at login-session; must match stored value (required in body).
fingerprint	Yes	SHA-256: 64 lowercase hex chars; must match the fingerprint from ①; a match means the same client.
fingerprint_method	Yes	Same convention as at issue; use S256

Example request body

{
  "refresh_token": "…",
  "client_veri_enc": "same PKCE code_challenge as at login-session",
  "fingerprint": "64-char lowercase hex (SHA-256 digest)",
  "fingerprint_method": "S256"
}

Response — example success body

{
  "success": true,
  "token": "<in-game access JWT>",
  "refresh_token": "…",
  "user": {
    "id": 1,
    "email": "user@example.com",
    "nick_name": "…",
    "profile_image": "https://…"
  }
}

Response fields

Name	Required	Description
success	Yes	true
token	Yes	New in-game access token (JWT). JSON field name: token
refresh_token	Yes	Same as the refresh_token sent in the request (no rotation). Clients may keep the stored value
user	Yes	id, email, nick_name, profile_image

On failure: HTTP 401 and error_code. On success the refresh row keeps the same hash; only expires_at is extended.

GET /game/auth/verify

Game client

Validates the in-game access token (JWT) via Authorization: Bearer. Same endpoint as the standard in-game login doc.

Live

https://api.fetamix.com/api/v1/game/auth/verify?

Sandbox

https://api-sandbox.fetamix.com/api/v1/game/auth/verify?

Headers

Name	Required	Description
Authorization	Yes	Bearer {in-game access JWT}

Query parameters

Name	Required	Description
key	No	Optional query param per server validation policy

Response — example success body

{
  "success": true,
  "data": {
    "valid": true,
    "sub": 1,
    "type": "app",
    "game_id": 1,
    "iat": 1761714925,
    "exp": 4825056125
  }
}

Response fields

Name	Required	Description
success	Yes	true
data.valid	Yes	true
data.sub	Yes	User id
data.type	Yes	e.g. app
data.game_id	Yes	Game id
data.device_key	No	May be present depending on server implementation
data.iat	Yes	Issued-at (unix)
data.exp	Yes	Expiry (unix)

Samples by integration step

Step 1 — POST /game/pc/auth/login-session (client)

var body = PcAuthJsonHelpers.BuildLoginSessionBody(
    clientVeriEnc,
    clientVerifier,
    clientSecret,
    pcOauthState,
    oauthLoopbackRedirectUriOrNull);

var url = $"{apiBaseUrl.TrimEnd('/')}/game/pc/auth/login-session";
using var req = new UnityWebRequest(url, "POST");
req.uploadHandler = new UploadHandlerRaw(Encoding.UTF8.GetBytes(body));
req.downloadHandler = new DownloadHandlerBuffer();
req.SetRequestHeader("Content-Type", "application/json");
yield return req.SendWebRequest();

Step 2 — Open google_oauth_start_url in the system browser

Application.OpenURL(googleOauthStartUrlFromLoginSession);

Step 3 — Receive one_time_token (loopback example)

using var loop = PcOAuthLoopbackReceiver.TryCreate(out var loopErr);
if (loop == null) { yield break; }

while (!loop.IsComplete) yield return null;
var oneTimeToken = loop.OneTimeToken;

Step 4 — Client → pc-auth-bridge (four fields)

yield return PcGameServerAuthClient.GetRefreshTokenCoroutine(
    gameServerBaseUrl, // pc-auth-bridge, e.g. https://pab.fetamix.com
    oneTimeToken,
    clientVeriEnc,
    fingerprintHex,
    onSuccessBody: json => { },
    onError: err => { });

Step 5 — Tokens the bridge returns (after it POSTs Fetamix)

// Game client does not POST Fetamix access-and-refresh-tokens.
// pc-auth-bridge does that hop and returns the same JSON:

{
  "success": true,
  "token": "<in-game access JWT>",
  "refresh_token": "…"
}

Step 6 — Client: refresh (no rotation) & JWT verify

6a — POST /game/pc/auth/refresh

var fp = PcDeviceFingerprint.ComputeSha256HexLower();
var body = PcAuthJsonHelpers.BuildRefreshBody(
    refreshToken, fp, "S256", clientVeriEnc);
// Unity sample uses pc-auth-bridge (gameServerBaseUrl). Fetamix apiBaseUrl also works.
var url = $"{gameServerBaseUrl.TrimEnd('/')}/game/pc/auth/refresh";
using var req = new UnityWebRequest(url, "POST");
req.uploadHandler = new UploadHandlerRaw(Encoding.UTF8.GetBytes(body));
req.downloadHandler = new DownloadHandlerBuffer();
req.SetRequestHeader("Content-Type", "application/json");
yield return req.SendWebRequest();

6b — GET /game/auth/verify

using var verifyReq = UnityWebRequest.Get($"{apiBaseUrl.TrimEnd('/')}/game/auth/verify");
verifyReq.SetRequestHeader("Authorization", "Bearer " + accessJwt);
verifyReq.downloadHandler = new DownloadHandlerBuffer();
yield return verifyReq.SendWebRequest();

In-game login (PC)

API base URL

Live

Sandbox

Fetamix endpoints (called by your code)

Integration steps and API details (1–6)

POST /game/pc/auth/login-session

JSON body fields

Example request body

Response — example success body

Response fields

`google_oauth_start_url` — open this URL in the **system browser**

Part of the opened URL (reference only)

Roughly what happens on the wire when that URL loads (reference)

Browser navigation (reference — do not parse in game code)

Local loopback

Game client → pc-auth-bridge

POST /game/pc/auth/access-and-refresh-tokens

JSON body fields

Example request body

Response — example success body

Response fields

POST /game/pc/auth/refresh

JSON body fields

Example request body

Response — example success body

Response fields

GET /game/auth/verify

Headers

Query parameters

Response — example success body

Response fields

Samples by integration step

Step 1 — POST /game/pc/auth/login-session (client)

Step 2 — Open google_oauth_start_url in the system browser

Step 3 — Receive one_time_token (loopback example)

Step 4 — Client → pc-auth-bridge (four fields)

Step 5 — Tokens the bridge returns (after it POSTs Fetamix)

Step 6 — Client: refresh (no rotation) & JWT verify

In-game login (PC)

API base URL

Live

Sandbox

Fetamix endpoints (called by your code)

Integration steps and API details (1–6)

POST /game/pc/auth/login-session

JSON body fields

Example request body

Response — example success body

Response fields

`google_oauth_start_url` — open this URL in the **system browser**

Part of the opened URL (reference only)

Roughly what happens on the wire when that URL loads (reference)

Browser navigation (reference — do not parse in game code)

Local loopback

Game client → pc-auth-bridge

POST /game/pc/auth/access-and-refresh-tokens

JSON body fields

Example request body

Response — example success body

Response fields

POST /game/pc/auth/refresh

JSON body fields

Example request body

Response — example success body

Response fields

GET /game/auth/verify

Headers

Query parameters

Response — example success body

Response fields

Samples by integration step

Step 1 — POST /game/pc/auth/login-session (client)

Step 2 — Open google_oauth_start_url in the system browser

Step 3 — Receive one_time_token (loopback example)

Step 4 — Client → pc-auth-bridge (four fields)

Step 5 — Tokens the bridge returns (after it POSTs Fetamix)

Step 6 — Client: refresh (no rotation) & JWT verify

`google_oauth_start_url` — open this URL in the system browser

`google_oauth_start_url` — open this URL in the system browser