PC auth bridge (client → bridge)

APIs the game client calls on pc-auth-bridge, which stands in for the game server token-exchange hop.

Flow: client → pc-auth-bridge → Fetamix `POST /api/v1/game/pc/auth/access-and-refresh-tokens`.

This host is not `api.fetamix.com`. Use `{BRIDGE_BASE}` below. Fetamix login-session / Google OAuth / verify stay on the Fetamix API — see In-game login (PC).

No Authorization header is required on the bridge. Do not send `client_verifier` here.

Bridge base URL

Live

https://pab.fetamix.com

Sandbox

https://pab-sandbox.fetamix.com

Set the client bridge base URL to this origin (no `/api/v1` suffix unless you use the alias paths).

1) Token exchange (recommended for the client)

After Google callback the client has `one_time_token`. POST the four fields to the bridge. The bridge forwards them to Fetamix and returns `token` (in-game access JWT) and `refresh_token`.

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

POST {BRIDGE_BASE}/game/pc/auth/access-and-refresh-tokens
Content-Type: application/json

JSON body

Name	In	Description
one_time_token	body	One-time token from Google OAuth callback / loopback.
client_veri_enc	body	Same PKCE code_challenge as login-session. Do not send client_verifier.
fingerprint	body	SHA-256 digest as 64 lowercase hex chars. Must match later refresh.
fingerprint_method	body	Fingerprint scheme. Currently `S256`.

Example request

{
  "one_time_token": "…",
  "client_veri_enc": "…",
  "fingerprint": "0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef",
  "fingerprint_method": "S256"
}

Example response

{
  "success": true,
  "token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9…",
  "refresh_token": "…"
}

2) Unity sample — GET /getrefreshToken

Same four fields as query parameters. Response body is identical to the POST exchange.

GET /getrefreshToken

GET {BRIDGE_BASE}/getrefreshToken?one_time_token=…&client_veri_enc=…&fingerprint=…&fingerprint_method=S256

Unity sample uses this GET. New clients can also POST `/getrefreshToken` or POST `/game/pc/auth/access-and-refresh-tokens` with the same four fields.

3) Refresh (optional via bridge)

You may still call Fetamix `POST /api/v1/game/pc/auth/refresh` directly. If the client talks only to the bridge, use this path instead. Response `token` is a new access JWT; `refresh_token` is the same value (no rotation).

POST /game/pc/auth/refresh

POST {BRIDGE_BASE}/game/pc/auth/refresh
Content-Type: application/json

JSON body

{
  "refresh_token": "…",
  "client_veri_enc": "…",
  "fingerprint": "0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef",
  "fingerprint_method": "S256"
}

Response fields

Field	Type	Description
success	boolean	true on success. On failure: success false plus error_code / message.
token	string	In-game access JWT. Store and send as Authorization: Bearer on Fetamix verify.
refresh_token	string	Refresh token plaintext. Reuse on later refresh (no rotation).

Notes for the client

• Call the bridge, not Fetamix, for token exchange.
• Send only `one_time_token` · `client_veri_enc` · `fingerprint` · `fingerprint_method`.
• `login-session`, Google OAuth, and `GET /game/auth/verify` remain on Fetamix API.
• Keep `fingerprint` identical on exchange and refresh.