Compatibility APIs
Player sessions, scores, and leaderboards.
The underlying game/session endpoints remain available for compatibility, but Studio does not add a game runtime to hosted apps.
No automatic browser bridge
Studio does not inject window.PlayFactory, window.RareGame, session tracking, or leaderboard code. A future integration can expose these capabilities as an explicit opt-in.
Public and session endpoints
POST …/sessions
Start a player or guest play session.
POST …/sessions/:id/complete
Complete a session with PlaySession authorization.
POST …/leaderboards/:key/scores
Submit an immutable score with PlaySession authorization and an Idempotency-Key.
GET …/leaderboards
List active boards and seasons.
GET …/leaderboards/:key/entries
Read ranked canonical-best entries with cursor pagination.
GET …/leaderboards/:key/me
Read the current player or guest entry.
GET …/leaderboards/:key/around-me
Read up to five entries above and below the current player.
POST /api/v1/players/claim-guest
Explicitly claim eligible guest scores after login.
Creator controls
An app owner can create and pause boards, choose higher- or lower-is-better ordering, set score units and bounds, limit submissions per session, schedule seasons, require authentication, inspect submissions, and invalidate or reinstate scores. Board keys must remain stable across deployments.
Client trust boundary
Never store session tokens or guest identifiers in app storage. A session-bound score proves it used a valid session, not that client-side game logic was impossible to manipulate. Use bounds, rate limits, moderation, and server-verifiable signals where stakes require them.