@ughuuu/game_server 1.0.1059 → 1.0.1070

package/README.md

@@ -1,7 +1,7 @@
 # @ughuuu/game_server
 
 UghuuuGameServer - JavaScript client for @ughuuu/game_server
-API for the Gamend Game Server. Provides HTTP REST API, real-time WebSocket channels, and WebRTC DataChannels for low-latency game data. Features authentication, users, lobbies, groups, parties, friends, chat, notifications, achievements, leaderboards, tournaments, matchmaking, payments, server scripting, and admin portal.
+API for the Gamend Game Server. Provides HTTP REST API, real-time WebSocket channels, and WebRTC DataChannels for low-latency game data. Features authentication, users, lobbies, groups, parties, friends, chat, notifications, quests, leaderboards, tournaments, matchmaking, payments, server scripting, and admin portal.
 
 ## **1. Authentication**
 
@@ -61,6 +61,16 @@ Persistent user-to-user notifications that survive across sessions:
 - **Delete notifications** by ID (single or batch)
 - **Real-time delivery** via the user WebSocket channel (`\"notification\"` events)
 - **Offline delivery**: undeleted notifications are replayed on WebSocket reconnect
+- **Push delivery**: notifications also fan out to the recipient's registered mobile devices (see Push notifications)
+
+## **5b. Push notifications**
+Mobile/web push delivery to registered devices (FCM for Android/Web, APNs-direct for iOS):
+
+- **Register device tokens** via `POST /me/push-tokens` (`token`, `platform`, optional `provider`/`device_id`); re-registering a `device_id` rotates its token in place
+- **List/remove own devices** via `GET /me/push-tokens` and `DELETE /me/push-tokens/:id`
+- **Server-authoritative sending** — no public send endpoint; pushes originate from server hooks (`GameServer.Push.send_to_user/2`) or the admin API
+- **Per-token routing**: each token's `provider` (\"fcm\" | \"apns\") selects the delivery backend; unconfigured backends log instead of sending (dev-friendly)
+- **Reliability**: delivery rides the durable job queue with retries; dead tokens reported by the provider are disabled automatically
 
 ## **6. Groups**
 Groups provide persistent community management for players:
@@ -110,15 +120,15 @@ Per-user persistent key-value storage for game state, preferences, and settings:
 - **List keys** with optional prefix filtering
 - **Metadata support**: values can include arbitrary JSON metadata
 
-## **11. Achievements**
-Track player accomplishments with progress-based or instant-unlock achievements:
+## **11. Quests / Progression**
+One event-driven progression engine covering achievements, daily/weekly quests, time-boxed event quests, and chains:
 
-- **Achievement definitions**: admin-created with slug, title, description, icon, sort order, and optional progress target
-- **Progress tracking**: increment progress toward a target; auto-unlocks when progress reaches the target
-- **Instant unlock**: directly unlock achievements without progress tracking
-- **Hidden achievements**: details obscured (\"???\") until unlocked by the user
-- **Public listings**: paginated, optionally filtered; authenticated users see their own progress
-- **Admin management**: create, update, delete, grant, revoke, unlock, and increment achievements
+- **Kinds**: `achievement` (permanent one-shot — the replacement for the old achievements system), `daily`/`weekly` (reset per UTC period), `event` (starts_at/ends_at window), `chain` (requires a prerequisite quest)
+- **Objectives**: each quest lists objectives `{event, target, params}`; server-side `report_event` advances every matching active quest — there is **no public endpoint to advance progress** (server-authoritative)
+- **Rewards**: currencies (Economy) and items (Inventory), paid **exactly once** per period via idempotent grants; `auto_claim` quests pay on completion, others via `POST /me/quests/:key/claim`
+- **My quests**: `GET /me/quests` returns active quests, per-period progress, and a claimable flag; hidden quests appear once completed
+- **Catalog**: `GET /quests` and per-user completions `GET /quests/user/:user_id` (gated by `LIST_QUESTS_ENABLED`)
+- **Admin management**: definitions CRUD plus per-user grant/reset/force-claim under `/api/v1/admin/quests`
 
 ## **12. Tournaments**
 Single-elimination bracket tournaments, server-structured and game-judged:
@@ -138,25 +148,35 @@ Ticket-based queueing that turns waiting players into hidden, locked lobbies:
 - **Inspect**: `GET /matchmaking/tickets/me` for your ticket, `GET /matchmaking/stats` for queue depths
 - **Admin management** over HTTP: list/filter tickets, force-cancel, and stats under `/api/v1/admin/matchmaking`
 
-## **14. Real-time: WebSocket Channels**
+## **14. Ready checks**
+One primitive for \"everyone must answer before this proceeds\", with one client-facing surface:
+
+- **A player holds at most one check per lane** — the match lane (lobby ready-up or matchmaking accept) and the party lane (the party's standing board) — so answering needs no id: `GET /me/ready_check` returns `{\"lobby\": …, \"party\": …}` (each null when none) and `POST /me/ready_check` with `{\"ready\": true|false, \"scope\": \"lobby\"|\"party\"}` answers one (scope defaults to `lobby`)
+- **Two kinds.** `ready` (lobby/party board) is a toggle — a \"no\" just leaves the check open, and it lists every participant. `accept` (match confirmation) is final — one decline fails it for everyone — and returns counts plus your own state, so a pending match does not reveal who you were paired with
+- **Hosts open one** with `POST /lobbies/ready_check` (host-managed lobbies only; hostless matchmaking lobbies belong to the server), **party leaders** with `POST /parties/ready_check`; either call is a **reset** — it quietly replaces an already-open board with a fresh one over the current members, so the same endpoint serves \"ready check!\", \"force ready\" (with `timeout_ms`) and \"start over\". Call it off with `DELETE /lobbies/ready_check` / `DELETE /parties/ready_check`. The opener is pre-marked ready — clicking the button is their answer
+- **Failure does nothing on its own**: a declined or timed-out check kicks nobody, starts nothing, and moves no lobby state. It reports who did not answer, and the game (or the host, with the kick they already have) decides
+- **Live**: `ready_check_started` / `ready_check_updated` / `ready_check_passed` / `ready_check_failed` on the lobby channel, the party channel for a party board, or the user channel for an accept check
+- **Admin management** over HTTP: list/filter checks, force-cancel, and 24h outcome stats under `/api/v1/admin/ready_checks`
+
+## **15. Real-time: WebSocket Channels**
 The server provides real-time communication via Phoenix WebSocket channels. Connect to the WebSocket endpoint and join topic-based channels for live updates.
 
-### **14.1 Connection**
+### **15.1 Connection**
 Connect to `wss://your-server.com/socket` with your JWT token as a parameter:
 ```
 const socket = new Socket(\"wss://your-server.com/socket\", { params: { token: \"<access_token>\" } })
 socket.connect()
 ```
 
-### **14.2 Available Channels**
-- **User channel** (`user:<user_id>`): notifications, friend events, achievement unlocks, party/group invites, tournament events, KV subscriptions
+### **15.2 Available Channels**
+- **User channel** (`user:<user_id>`): notifications, friend events, quest progress/completions/claims, party/group invites, tournament events, KV subscriptions
 - **Lobby channel** (`lobby:<lobby_id>`): lobby member joins/leaves, lobby updates, lobby chat
 - **Lobbies channel** (`lobbies`): global lobby list changes (created, updated, deleted)
 - **Group channel** (`group:<group_id>`): group member changes, group updates, group chat
 - **Groups channel** (`groups`): global group list changes
 - **Party channel** (`party:<party_id>`): party member changes, party updates, party chat
 
-### **14.3 JS SDK Helper**
+### **15.3 JS SDK Helper**
 The `GameRealtime` class (included in this SDK) wraps Phoenix.Socket with convenient channel helpers:
 ```javascript
 import { GameRealtime } from '@ughuuu/game_server'
@@ -166,21 +186,21 @@ userChannel.on('notification', payload => console.log(payload))
 ```
 Requires the `phoenix` npm package as a peer dependency: `npm install phoenix`
 
-## **15. Real-time: WebRTC DataChannels**
+## **16. Real-time: WebRTC DataChannels**
 For low-latency game data, the server supports WebRTC DataChannels alongside WebSocket. The server acts as a WebRTC peer (not P2P between clients).
 
-### **15.1 How It Works**
+### **16.1 How It Works**
 1. Client connects via WebSocket and joins the **User channel**
 2. Client sends an SDP offer over the channel (`webrtc:offer` event)
 3. Server responds with an SDP answer (`webrtc:answer` event)
 4. ICE candidates are exchanged (`webrtc:ice` events)
 5. Once connected, named DataChannels carry game data at low latency
 
-### **15.2 Default DataChannels**
+### **16.2 Default DataChannels**
 - **`events`** (reliable, ordered): important game events (player actions, state changes)
 - **`state`** (unreliable, unordered): high-frequency position/state sync
 
-### **15.3 JS SDK Helper**
+### **16.3 JS SDK Helper**
 The `GameWebRTC` class (included in this SDK, browser-only) handles signaling automatically:
 ```javascript
 import { GameRealtime, GameWebRTC } from '@ughuuu/game_server'
@@ -195,7 +215,7 @@ webrtc.send('events', JSON.stringify({ type: 'move', x: 10, y: 20 }))
 
 This SDK is automatically generated by the [OpenAPI Generator](https://openapi-generator.tech) project:
 
-- API version: 1.0.1059
+- API version: 1.0.1070
 - Package version: 1.0.0
 - Generator version: 7.24.0
 - Build package: org.openapitools.codegen.languages.JavascriptClientCodegen
@@ -292,10 +312,15 @@ Please follow the [installation](#installation) instruction and execute the foll
 ```javascript
 var UghuuuGameServer = require('@ughuuu/game_server');
 
+var defaultClient = UghuuuGameServer.ApiClient.instance;
+// Configure Bearer (JWT) access token for authorization: authorization
+var authorization = defaultClient.authentications['authorization'];
+authorization.accessToken = "YOUR ACCESS TOKEN"
 
-var api = new UghuuuGameServer.AchievementsApi()
-var slug = "slug_example"; // {String} 
-api.getAchievement(slug).then(function(data) {
+var api = new UghuuuGameServer.AdminChatApi()
+var chatType = "chatType_example"; // {String} 
+var chatRefId = "chatRefId_example"; // {String} 
+api.adminDeleteChatConversation(chatType, chatRefId).then(function(data) {
   console.log('API called successfully. Returned data: ' + data);
 }, function(error) {
   console.error(error);
@@ -310,18 +335,6 @@ All URIs are relative to *http://localhost:4000*
 
 Class | Method | HTTP request | Description
 ------------ | ------------- | ------------- | -------------
-*UghuuuGameServer.AchievementsApi* | [**getAchievement**](docs/AchievementsApi.md#getAchievement) | **GET** /api/v1/achievements/{slug} | Get achievement details
-*UghuuuGameServer.AchievementsApi* | [**listAchievements**](docs/AchievementsApi.md#listAchievements) | **GET** /api/v1/achievements | List achievements
-*UghuuuGameServer.AchievementsApi* | [**myAchievements**](docs/AchievementsApi.md#myAchievements) | **GET** /api/v1/achievements/me | List my unlocked achievements
-*UghuuuGameServer.AchievementsApi* | [**userAchievements**](docs/AchievementsApi.md#userAchievements) | **GET** /api/v1/achievements/user/{user_id} | List a user&#39;s unlocked achievements
-*UghuuuGameServer.AdminAchievementsApi* | [**adminCreateAchievement**](docs/AdminAchievementsApi.md#adminCreateAchievement) | **POST** /api/v1/admin/achievements | Create achievement (admin)
-*UghuuuGameServer.AdminAchievementsApi* | [**adminDeleteAchievement**](docs/AdminAchievementsApi.md#adminDeleteAchievement) | **DELETE** /api/v1/admin/achievements/{id} | Delete achievement (admin)
-*UghuuuGameServer.AdminAchievementsApi* | [**adminGrantAchievement**](docs/AdminAchievementsApi.md#adminGrantAchievement) | **POST** /api/v1/admin/achievements/grant | Grant achievement to user (admin)
-*UghuuuGameServer.AdminAchievementsApi* | [**adminIncrementAchievement**](docs/AdminAchievementsApi.md#adminIncrementAchievement) | **POST** /api/v1/admin/achievements/increment | Increment achievement progress for user (admin)
-*UghuuuGameServer.AdminAchievementsApi* | [**adminListAchievements**](docs/AdminAchievementsApi.md#adminListAchievements) | **GET** /api/v1/admin/achievements | List all achievements (admin, includes hidden)
-*UghuuuGameServer.AdminAchievementsApi* | [**adminRevokeAchievement**](docs/AdminAchievementsApi.md#adminRevokeAchievement) | **POST** /api/v1/admin/achievements/revoke | Revoke achievement from user (admin)
-*UghuuuGameServer.AdminAchievementsApi* | [**adminUnlockAchievement**](docs/AdminAchievementsApi.md#adminUnlockAchievement) | **POST** /api/v1/admin/achievements/unlock | Unlock achievement for user (admin)
-*UghuuuGameServer.AdminAchievementsApi* | [**adminUpdateAchievement**](docs/AdminAchievementsApi.md#adminUpdateAchievement) | **PATCH** /api/v1/admin/achievements/{id} | Update achievement (admin)
 *UghuuuGameServer.AdminChatApi* | [**adminDeleteChatConversation**](docs/AdminChatApi.md#adminDeleteChatConversation) | **DELETE** /api/v1/admin/chat/conversation | Delete all messages in a conversation (admin)
 *UghuuuGameServer.AdminChatApi* | [**adminDeleteChatMessage**](docs/AdminChatApi.md#adminDeleteChatMessage) | **DELETE** /api/v1/admin/chat/{id} | Delete a chat message (admin)
 *UghuuuGameServer.AdminChatApi* | [**adminListChatMessages**](docs/AdminChatApi.md#adminListChatMessages) | **GET** /api/v1/admin/chat | List all chat messages (admin)
@@ -358,6 +371,23 @@ Class | Method | HTTP request | Description
 *UghuuuGameServer.AdminNotificationsApi* | [**adminCreateNotification**](docs/AdminNotificationsApi.md#adminCreateNotification) | **POST** /api/v1/admin/notifications | Create a notification (admin)
 *UghuuuGameServer.AdminNotificationsApi* | [**adminDeleteNotification**](docs/AdminNotificationsApi.md#adminDeleteNotification) | **DELETE** /api/v1/admin/notifications/{id} | Delete a notification (admin)
 *UghuuuGameServer.AdminNotificationsApi* | [**adminListNotifications**](docs/AdminNotificationsApi.md#adminListNotifications) | **GET** /api/v1/admin/notifications | List all notifications (admin)
+*UghuuuGameServer.AdminPushApi* | [**adminDeletePushToken**](docs/AdminPushApi.md#adminDeletePushToken) | **DELETE** /api/v1/admin/push/tokens/{id} | Delete a device push token (admin)
+*UghuuuGameServer.AdminPushApi* | [**adminListPushTokens**](docs/AdminPushApi.md#adminListPushTokens) | **GET** /api/v1/admin/push/tokens | List registered device push tokens (admin)
+*UghuuuGameServer.AdminPushApi* | [**adminSendPush**](docs/AdminPushApi.md#adminSendPush) | **POST** /api/v1/admin/push/send | Send a push notification to a user (admin)
+*UghuuuGameServer.AdminQuestsApi* | [**adminClaimQuest**](docs/AdminQuestsApi.md#adminClaimQuest) | **POST** /api/v1/admin/quests/claim | Claim a completed quest on a user&#39;s behalf (admin)
+*UghuuuGameServer.AdminQuestsApi* | [**adminCreateQuest**](docs/AdminQuestsApi.md#adminCreateQuest) | **POST** /api/v1/admin/quests | Create quest (admin)
+*UghuuuGameServer.AdminQuestsApi* | [**adminDeleteQuest**](docs/AdminQuestsApi.md#adminDeleteQuest) | **DELETE** /api/v1/admin/quests/{id} | Delete quest and all user progress (admin)
+*UghuuuGameServer.AdminQuestsApi* | [**adminGrantQuest**](docs/AdminQuestsApi.md#adminGrantQuest) | **POST** /api/v1/admin/quests/grant | Force-complete a quest for a user (admin)
+*UghuuuGameServer.AdminQuestsApi* | [**adminListQuestProgress**](docs/AdminQuestsApi.md#adminListQuestProgress) | **GET** /api/v1/admin/quests/progress | List quest progress rows (admin)
+*UghuuuGameServer.AdminQuestsApi* | [**adminListQuests**](docs/AdminQuestsApi.md#adminListQuests) | **GET** /api/v1/admin/quests | List all quest definitions (admin, includes inactive/hidden)
+*UghuuuGameServer.AdminQuestsApi* | [**adminQuestFunnel**](docs/AdminQuestsApi.md#adminQuestFunnel) | **GET** /api/v1/admin/quests/{key}/funnel | Per-status progress counts for one quest (admin)
+*UghuuuGameServer.AdminQuestsApi* | [**adminResetQuest**](docs/AdminQuestsApi.md#adminResetQuest) | **POST** /api/v1/admin/quests/reset | Reset a user&#39;s current-period quest progress (admin)
+*UghuuuGameServer.AdminQuestsApi* | [**adminUpdateQuest**](docs/AdminQuestsApi.md#adminUpdateQuest) | **PATCH** /api/v1/admin/quests/{id} | Update quest (admin)
+*UghuuuGameServer.AdminReadyChecksApi* | [**adminCancelReadyCheck**](docs/AdminReadyChecksApi.md#adminCancelReadyCheck) | **DELETE** /api/v1/admin/ready_checks/{id} | Force-cancel a pending ready check (admin)
+*UghuuuGameServer.AdminReadyChecksApi* | [**adminListReadyChecks**](docs/AdminReadyChecksApi.md#adminListReadyChecks) | **GET** /api/v1/admin/ready_checks | List ready checks (admin)
+*UghuuuGameServer.AdminReadyChecksApi* | [**adminReadyCheckStats**](docs/AdminReadyChecksApi.md#adminReadyCheckStats) | **GET** /api/v1/admin/ready_checks/stats | Ready check outcomes over the last 24 hours (admin)
+*UghuuuGameServer.AdminRetentionApi* | [**adminGetRetentionStatus**](docs/AdminRetentionApi.md#adminGetRetentionStatus) | **GET** /api/v1/admin/retention | Last retention sweep (admin)
+*UghuuuGameServer.AdminRetentionApi* | [**adminRunRetention**](docs/AdminRetentionApi.md#adminRunRetention) | **POST** /api/v1/admin/retention/run | Run a retention sweep now (admin)
 *UghuuuGameServer.AdminSessionsApi* | [**adminDeleteSession**](docs/AdminSessionsApi.md#adminDeleteSession) | **DELETE** /api/v1/admin/sessions/{id} | Delete session token by id (admin)
 *UghuuuGameServer.AdminSessionsApi* | [**adminDeleteUserSessions**](docs/AdminSessionsApi.md#adminDeleteUserSessions) | **DELETE** /api/v1/admin/users/{id}/sessions | Delete all session tokens for a user (admin)
 *UghuuuGameServer.AdminSessionsApi* | [**adminListSessions**](docs/AdminSessionsApi.md#adminListSessions) | **GET** /api/v1/admin/sessions | List sessions (admin)
@@ -448,6 +478,7 @@ Class | Method | HTTP request | Description
 *UghuuuGameServer.LobbiesApi* | [**leaveLobby**](docs/LobbiesApi.md#leaveLobby) | **POST** /api/v1/lobbies/leave | Leave the current lobby
 *UghuuuGameServer.LobbiesApi* | [**listLobbies**](docs/LobbiesApi.md#listLobbies) | **GET** /api/v1/lobbies | List lobbies
 *UghuuuGameServer.LobbiesApi* | [**quickJoin**](docs/LobbiesApi.md#quickJoin) | **POST** /api/v1/lobbies/quick_join | Quick-join or create a lobby
+*UghuuuGameServer.LobbiesApi* | [**setLobbyState**](docs/LobbiesApi.md#setLobbyState) | **POST** /api/v1/lobbies/state | Set lobby state (host only)
 *UghuuuGameServer.LobbiesApi* | [**updateLobby**](docs/LobbiesApi.md#updateLobby) | **PATCH** /api/v1/lobbies | Update lobby (host only)
 *UghuuuGameServer.MatchmakingApi* | [**matchmakingCancel**](docs/MatchmakingApi.md#matchmakingCancel) | **DELETE** /api/v1/matchmaking/tickets | Leave the matchmaking queue
 *UghuuuGameServer.MatchmakingApi* | [**matchmakingJoin**](docs/MatchmakingApi.md#matchmakingJoin) | **POST** /api/v1/matchmaking/tickets | Join the matchmaking queue
@@ -478,6 +509,19 @@ Class | Method | HTTP request | Description
 *UghuuuGameServer.PaymentsApi* | [**paymentsStripeCheckout**](docs/PaymentsApi.md#paymentsStripeCheckout) | **POST** /api/v1/payments/checkout/stripe | Create a Stripe Checkout Session
 *UghuuuGameServer.PaymentsApi* | [**paymentsStripeWebhook**](docs/PaymentsApi.md#paymentsStripeWebhook) | **POST** /api/v1/payments/webhooks/stripe | Receive Stripe webhook events
 *UghuuuGameServer.PaymentsApi* | [**paymentsValidateStorePurchase**](docs/PaymentsApi.md#paymentsValidateStorePurchase) | **POST** /api/v1/payments/validate/{provider} | Validate an Apple, Google, or Steam purchase
+*UghuuuGameServer.PushApi* | [**deletePushToken**](docs/PushApi.md#deletePushToken) | **DELETE** /api/v1/me/push-tokens/{id} | Unregister one of the current user&#39;s devices
+*UghuuuGameServer.PushApi* | [**listPushTokens**](docs/PushApi.md#listPushTokens) | **GET** /api/v1/me/push-tokens | List the current user&#39;s registered devices
+*UghuuuGameServer.PushApi* | [**registerPushToken**](docs/PushApi.md#registerPushToken) | **POST** /api/v1/me/push-tokens | Register a device push token
+*UghuuuGameServer.QuestsApi* | [**claimQuest**](docs/QuestsApi.md#claimQuest) | **POST** /api/v1/me/quests/{key}/claim | Claim a completed quest
+*UghuuuGameServer.QuestsApi* | [**listQuests**](docs/QuestsApi.md#listQuests) | **GET** /api/v1/quests | List quests
+*UghuuuGameServer.QuestsApi* | [**myQuests**](docs/QuestsApi.md#myQuests) | **GET** /api/v1/me/quests | List my quests
+*UghuuuGameServer.QuestsApi* | [**userQuests**](docs/QuestsApi.md#userQuests) | **GET** /api/v1/quests/user/{user_id} | List a user&#39;s completed quests
+*UghuuuGameServer.ReadyChecksApi* | [**cancelLobbyReadyCheck**](docs/ReadyChecksApi.md#cancelLobbyReadyCheck) | **DELETE** /api/v1/lobbies/ready_check | Call off the ready check in the caller&#39;s lobby (host only)
+*UghuuuGameServer.ReadyChecksApi* | [**cancelPartyReadyCheck**](docs/ReadyChecksApi.md#cancelPartyReadyCheck) | **DELETE** /api/v1/parties/ready_check | Call off the ready check in the caller&#39;s party (leader only)
+*UghuuuGameServer.ReadyChecksApi* | [**getMyReadyCheck**](docs/ReadyChecksApi.md#getMyReadyCheck) | **GET** /api/v1/me/ready_check | Get the caller&#39;s open ready checks
+*UghuuuGameServer.ReadyChecksApi* | [**openLobbyReadyCheck**](docs/ReadyChecksApi.md#openLobbyReadyCheck) | **POST** /api/v1/lobbies/ready_check | Open (or reset) the ready board in the caller&#39;s lobby (host only)
+*UghuuuGameServer.ReadyChecksApi* | [**openPartyReadyCheck**](docs/ReadyChecksApi.md#openPartyReadyCheck) | **POST** /api/v1/parties/ready_check | Open (or reset) the ready board in the caller&#39;s party (leader only)
+*UghuuuGameServer.ReadyChecksApi* | [**respondReadyCheck**](docs/ReadyChecksApi.md#respondReadyCheck) | **POST** /api/v1/me/ready_check | Answer one of the caller&#39;s open ready checks
 *UghuuuGameServer.TournamentsApi* | [**getTournament**](docs/TournamentsApi.md#getTournament) | **GET** /api/v1/tournaments/{id} | Tournament details (with the caller&#39;s participation when authenticated)
 *UghuuuGameServer.TournamentsApi* | [**joinTournament**](docs/TournamentsApi.md#joinTournament) | **POST** /api/v1/tournaments/{id}/join | Register as an entry leader
 *UghuuuGameServer.TournamentsApi* | [**leaveTournament**](docs/TournamentsApi.md#leaveTournament) | **DELETE** /api/v1/tournaments/{id}/join | Withdraw the caller&#39;s entry (before the draw)
@@ -503,19 +547,19 @@ Class | Method | HTTP request | Description
  - [UghuuuGameServer.AcceptPartyInvite200ResponseMembersInner](docs/AcceptPartyInvite200ResponseMembersInner.md)
  - [UghuuuGameServer.AcceptPartyInviteRequest](docs/AcceptPartyInviteRequest.md)
  - [UghuuuGameServer.AdminCancelMatchmakingTicket200Response](docs/AdminCancelMatchmakingTicket200Response.md)
- - [UghuuuGameServer.AdminCreateAchievementRequest](docs/AdminCreateAchievementRequest.md)
+ - [UghuuuGameServer.AdminCancelReadyCheck200Response](docs/AdminCancelReadyCheck200Response.md)
+ - [UghuuuGameServer.AdminCancelReadyCheck200ResponseData](docs/AdminCancelReadyCheck200ResponseData.md)
  - [UghuuuGameServer.AdminCreateLeaderboard200Response](docs/AdminCreateLeaderboard200Response.md)
  - [UghuuuGameServer.AdminCreateLeaderboard200ResponseData](docs/AdminCreateLeaderboard200ResponseData.md)
  - [UghuuuGameServer.AdminCreateLeaderboardRequest](docs/AdminCreateLeaderboardRequest.md)
  - [UghuuuGameServer.AdminCreateNotificationRequest](docs/AdminCreateNotificationRequest.md)
+ - [UghuuuGameServer.AdminCreateQuestRequest](docs/AdminCreateQuestRequest.md)
+ - [UghuuuGameServer.AdminCreateQuestRequestObjectivesInner](docs/AdminCreateQuestRequestObjectivesInner.md)
+ - [UghuuuGameServer.AdminCreateQuestRequestRewardsInner](docs/AdminCreateQuestRequestRewardsInner.md)
  - [UghuuuGameServer.AdminDeleteChatConversation200Response](docs/AdminDeleteChatConversation200Response.md)
  - [UghuuuGameServer.AdminDrawTournament200Response](docs/AdminDrawTournament200Response.md)
  - [UghuuuGameServer.AdminDrawTournament200ResponseData](docs/AdminDrawTournament200ResponseData.md)
- - [UghuuuGameServer.AdminGrantAchievementRequest](docs/AdminGrantAchievementRequest.md)
  - [UghuuuGameServer.AdminGrantItemRequest](docs/AdminGrantItemRequest.md)
- - [UghuuuGameServer.AdminIncrementAchievementRequest](docs/AdminIncrementAchievementRequest.md)
- - [UghuuuGameServer.AdminListAchievements200Response](docs/AdminListAchievements200Response.md)
- - [UghuuuGameServer.AdminListAchievements200ResponseDataInner](docs/AdminListAchievements200ResponseDataInner.md)
  - [UghuuuGameServer.AdminListChatMessages200Response](docs/AdminListChatMessages200Response.md)
  - [UghuuuGameServer.AdminListChatMessages200ResponseDataInner](docs/AdminListChatMessages200ResponseDataInner.md)
  - [UghuuuGameServer.AdminListGroups200Response](docs/AdminListGroups200Response.md)
@@ -526,6 +570,13 @@ Class | Method | HTTP request | Description
  - [UghuuuGameServer.AdminListMatchmakingTickets200ResponseDataInner](docs/AdminListMatchmakingTickets200ResponseDataInner.md)
  - [UghuuuGameServer.AdminListNotifications200Response](docs/AdminListNotifications200Response.md)
  - [UghuuuGameServer.AdminListNotifications200ResponseDataInner](docs/AdminListNotifications200ResponseDataInner.md)
+ - [UghuuuGameServer.AdminListPushTokens200Response](docs/AdminListPushTokens200Response.md)
+ - [UghuuuGameServer.AdminListPushTokens200ResponseDataInner](docs/AdminListPushTokens200ResponseDataInner.md)
+ - [UghuuuGameServer.AdminListQuestProgress200Response](docs/AdminListQuestProgress200Response.md)
+ - [UghuuuGameServer.AdminListQuestProgress200ResponseDataInner](docs/AdminListQuestProgress200ResponseDataInner.md)
+ - [UghuuuGameServer.AdminListQuests200Response](docs/AdminListQuests200Response.md)
+ - [UghuuuGameServer.AdminListQuests200ResponseDataInner](docs/AdminListQuests200ResponseDataInner.md)
+ - [UghuuuGameServer.AdminListReadyChecks200Response](docs/AdminListReadyChecks200Response.md)
  - [UghuuuGameServer.AdminListSessions200Response](docs/AdminListSessions200Response.md)
  - [UghuuuGameServer.AdminListSessions200ResponseDataInner](docs/AdminListSessions200ResponseDataInner.md)
  - [UghuuuGameServer.AdminListStorageObjects200Response](docs/AdminListStorageObjects200Response.md)
@@ -533,11 +584,12 @@ Class | Method | HTTP request | Description
  - [UghuuuGameServer.AdminListStorageObjects200ResponseUsage](docs/AdminListStorageObjects200ResponseUsage.md)
  - [UghuuuGameServer.AdminMatchmakingStats200Response](docs/AdminMatchmakingStats200Response.md)
  - [UghuuuGameServer.AdminMatchmakingStats200ResponseData](docs/AdminMatchmakingStats200ResponseData.md)
+ - [UghuuuGameServer.AdminResetQuestRequest](docs/AdminResetQuestRequest.md)
  - [UghuuuGameServer.AdminResolveTournamentMatchRequest](docs/AdminResolveTournamentMatchRequest.md)
- - [UghuuuGameServer.AdminRevokeAchievementRequest](docs/AdminRevokeAchievementRequest.md)
+ - [UghuuuGameServer.AdminRunRetention200Response](docs/AdminRunRetention200Response.md)
+ - [UghuuuGameServer.AdminSendPushRequest](docs/AdminSendPushRequest.md)
  - [UghuuuGameServer.AdminSpendCurrencyRequest](docs/AdminSpendCurrencyRequest.md)
  - [UghuuuGameServer.AdminSubmitLeaderboardScoreRequest](docs/AdminSubmitLeaderboardScoreRequest.md)
- - [UghuuuGameServer.AdminUpdateAchievementRequest](docs/AdminUpdateAchievementRequest.md)
  - [UghuuuGameServer.AdminUpdateGroup200Response](docs/AdminUpdateGroup200Response.md)
  - [UghuuuGameServer.AdminUpdateGroupRequest](docs/AdminUpdateGroupRequest.md)
  - [UghuuuGameServer.AdminUpdateKvEntryRequest](docs/AdminUpdateKvEntryRequest.md)
@@ -560,6 +612,8 @@ Class | Method | HTTP request | Description
  - [UghuuuGameServer.CancelJoinRequest200Response](docs/CancelJoinRequest200Response.md)
  - [UghuuuGameServer.CancelPartyInviteRequest](docs/CancelPartyInviteRequest.md)
  - [UghuuuGameServer.ChatUnreadCount200Response](docs/ChatUnreadCount200Response.md)
+ - [UghuuuGameServer.ClaimQuest200Response](docs/ClaimQuest200Response.md)
+ - [UghuuuGameServer.ClaimQuest200ResponseData](docs/ClaimQuest200ResponseData.md)
  - [UghuuuGameServer.CreateCurrentUserAvatarUploadUrlRequest](docs/CreateCurrentUserAvatarUploadUrlRequest.md)
  - [UghuuuGameServer.CreateFriendRequestRequest](docs/CreateFriendRequestRequest.md)
  - [UghuuuGameServer.CreateGroupRequest](docs/CreateGroupRequest.md)
@@ -569,6 +623,7 @@ Class | Method | HTTP request | Description
  - [UghuuuGameServer.DeclinePartyInviteRequest](docs/DeclinePartyInviteRequest.md)
  - [UghuuuGameServer.DeleteNotifications200Response](docs/DeleteNotifications200Response.md)
  - [UghuuuGameServer.DeleteNotificationsRequest](docs/DeleteNotificationsRequest.md)
+ - [UghuuuGameServer.DeletePushToken200Response](docs/DeletePushToken200Response.md)
  - [UghuuuGameServer.DemoteGroupMemberRequest](docs/DemoteGroupMemberRequest.md)
  - [UghuuuGameServer.DeviceLoginRequest](docs/DeviceLoginRequest.md)
  - [UghuuuGameServer.ErrorResponse](docs/ErrorResponse.md)
@@ -577,6 +632,9 @@ Class | Method | HTTP request | Description
  - [UghuuuGameServer.GetCurrentUserInventory200Response](docs/GetCurrentUserInventory200Response.md)
  - [UghuuuGameServer.GetKv200Response](docs/GetKv200Response.md)
  - [UghuuuGameServer.GetLobby200Response](docs/GetLobby200Response.md)
+ - [UghuuuGameServer.GetMyReadyCheck200Response](docs/GetMyReadyCheck200Response.md)
+ - [UghuuuGameServer.GetMyReadyCheck200ResponseLobby](docs/GetMyReadyCheck200ResponseLobby.md)
+ - [UghuuuGameServer.GetMyReadyCheck200ResponseParty](docs/GetMyReadyCheck200ResponseParty.md)
  - [UghuuuGameServer.GetMyRecord200Response](docs/GetMyRecord200Response.md)
  - [UghuuuGameServer.GetMyRecord200ResponseData](docs/GetMyRecord200ResponseData.md)
  - [UghuuuGameServer.HealthResponse](docs/HealthResponse.md)
@@ -601,7 +659,6 @@ Class | Method | HTTP request | Description
  - [UghuuuGameServer.ListFriendRequests200ResponseMeta](docs/ListFriendRequests200ResponseMeta.md)
  - [UghuuuGameServer.ListFriends200Response](docs/ListFriends200Response.md)
  - [UghuuuGameServer.ListFriends200ResponseDataInner](docs/ListFriends200ResponseDataInner.md)
- - [UghuuuGameServer.ListFriends200ResponseMeta](docs/ListFriends200ResponseMeta.md)
  - [UghuuuGameServer.ListGroupInvitations200Response](docs/ListGroupInvitations200Response.md)
  - [UghuuuGameServer.ListGroupInvitations200ResponseDataInner](docs/ListGroupInvitations200ResponseDataInner.md)
  - [UghuuuGameServer.ListGroupMembers200Response](docs/ListGroupMembers200Response.md)
@@ -615,6 +672,7 @@ Class | Method | HTTP request | Description
  - [UghuuuGameServer.ListNotifications200Response](docs/ListNotifications200Response.md)
  - [UghuuuGameServer.ListNotifications200ResponseDataInner](docs/ListNotifications200ResponseDataInner.md)
  - [UghuuuGameServer.ListPartyInvitations200ResponseInner](docs/ListPartyInvitations200ResponseInner.md)
+ - [UghuuuGameServer.ListPushTokens200Response](docs/ListPushTokens200Response.md)
  - [UghuuuGameServer.ListRecordsAroundUser200Response](docs/ListRecordsAroundUser200Response.md)
  - [UghuuuGameServer.ListSentInvitations200Response](docs/ListSentInvitations200Response.md)
  - [UghuuuGameServer.ListSentInvitations200ResponseDataInner](docs/ListSentInvitations200ResponseDataInner.md)
@@ -633,8 +691,6 @@ Class | Method | HTTP request | Description
  - [UghuuuGameServer.MatchmakingStats200Response](docs/MatchmakingStats200Response.md)
  - [UghuuuGameServer.MatchmakingStats200ResponseData](docs/MatchmakingStats200ResponseData.md)
  - [UghuuuGameServer.MatchmakingStats200ResponseDataQueuesInner](docs/MatchmakingStats200ResponseDataQueuesInner.md)
- - [UghuuuGameServer.MyAchievements200Response](docs/MyAchievements200Response.md)
- - [UghuuuGameServer.MyAchievements200ResponseDataInner](docs/MyAchievements200ResponseDataInner.md)
  - [UghuuuGameServer.NotifyGroup200Response](docs/NotifyGroup200Response.md)
  - [UghuuuGameServer.NotifyGroupRequest](docs/NotifyGroupRequest.md)
  - [UghuuuGameServer.OAuthSessionData](docs/OAuthSessionData.md)
@@ -646,6 +702,8 @@ Class | Method | HTTP request | Description
  - [UghuuuGameServer.OauthGoogleIdTokenRequest](docs/OauthGoogleIdTokenRequest.md)
  - [UghuuuGameServer.OauthRequest200Response](docs/OauthRequest200Response.md)
  - [UghuuuGameServer.OauthSessionStatus404Response](docs/OauthSessionStatus404Response.md)
+ - [UghuuuGameServer.OpenLobbyReadyCheck201Response](docs/OpenLobbyReadyCheck201Response.md)
+ - [UghuuuGameServer.OpenLobbyReadyCheckRequest](docs/OpenLobbyReadyCheckRequest.md)
  - [UghuuuGameServer.PartyCreateLobbyRequest](docs/PartyCreateLobbyRequest.md)
  - [UghuuuGameServer.PartyJoinLobbyRequest](docs/PartyJoinLobbyRequest.md)
  - [UghuuuGameServer.PaymentsSteamCheckoutRequest](docs/PaymentsSteamCheckoutRequest.md)
@@ -656,14 +714,17 @@ Class | Method | HTTP request | Description
  - [UghuuuGameServer.RefreshToken200Response](docs/RefreshToken200Response.md)
  - [UghuuuGameServer.RefreshToken200ResponseData](docs/RefreshToken200ResponseData.md)
  - [UghuuuGameServer.RefreshTokenRequest](docs/RefreshTokenRequest.md)
+ - [UghuuuGameServer.RegisterPushTokenRequest](docs/RegisterPushTokenRequest.md)
  - [UghuuuGameServer.ResolveLeaderboardSlugs200Response](docs/ResolveLeaderboardSlugs200Response.md)
  - [UghuuuGameServer.ResolveLeaderboardSlugs200ResponseDataValue](docs/ResolveLeaderboardSlugs200ResponseDataValue.md)
  - [UghuuuGameServer.ResolveLeaderboardSlugsRequest](docs/ResolveLeaderboardSlugsRequest.md)
+ - [UghuuuGameServer.RespondReadyCheckRequest](docs/RespondReadyCheckRequest.md)
  - [UghuuuGameServer.SearchUsers200Response](docs/SearchUsers200Response.md)
  - [UghuuuGameServer.SearchUsers200ResponseDataInner](docs/SearchUsers200ResponseDataInner.md)
  - [UghuuuGameServer.SendChatMessageRequest](docs/SendChatMessageRequest.md)
  - [UghuuuGameServer.SendNotificationRequest](docs/SendNotificationRequest.md)
  - [UghuuuGameServer.SetCurrentUserAvatarRequest](docs/SetCurrentUserAvatarRequest.md)
+ - [UghuuuGameServer.SetLobbyStateRequest](docs/SetLobbyStateRequest.md)
  - [UghuuuGameServer.TournamentMyMatch200Response](docs/TournamentMyMatch200Response.md)
  - [UghuuuGameServer.UpdateChatMessageRequest](docs/UpdateChatMessageRequest.md)
  - [UghuuuGameServer.UpdateCurrentUserDisplayName400Response](docs/UpdateCurrentUserDisplayName400Response.md)
@@ -673,6 +734,12 @@ Class | Method | HTTP request | Description
  - [UghuuuGameServer.UpdateGroupRequest](docs/UpdateGroupRequest.md)
  - [UghuuuGameServer.UpdateLobbyRequest](docs/UpdateLobbyRequest.md)
  - [UghuuuGameServer.UpdatePartyRequest](docs/UpdatePartyRequest.md)
+ - [UghuuuGameServer.UserQuests200Response](docs/UserQuests200Response.md)
+ - [UghuuuGameServer.UserQuests200ResponseDataInner](docs/UserQuests200ResponseDataInner.md)
+ - [UghuuuGameServer.UserQuests200ResponseDataInnerObjectivesInner](docs/UserQuests200ResponseDataInnerObjectivesInner.md)
+ - [UghuuuGameServer.UserQuests200ResponseDataInnerProgress](docs/UserQuests200ResponseDataInnerProgress.md)
+ - [UghuuuGameServer.UserQuests200ResponseDataInnerRewardsInner](docs/UserQuests200ResponseDataInnerRewardsInner.md)
+ - [UghuuuGameServer.UserQuests200ResponseMeta](docs/UserQuests200ResponseMeta.md)
 
 
 ## Documentation for Authorization

package/dist/ApiClient.js

@@ -13,9 +13,9 @@ function _createClass(e, r, t) { return r && _defineProperties(e.prototype, r),
 function _toPropertyKey(t) { var i = _toPrimitive(t, "string"); return "symbol" == _typeof(i) ? i : i + ""; }
 function _toPrimitive(t, r) { if ("object" != _typeof(t) || !t) return t; var e = t[Symbol.toPrimitive]; if (void 0 !== e) { var i = e.call(t, r || "default"); if ("object" != _typeof(i)) return i; throw new TypeError("@@toPrimitive must return a primitive value."); } return ("string" === r ? String : Number)(t); } /**
  * Game Server API
- * API for the Gamend Game Server. Provides HTTP REST API, real-time WebSocket channels, and WebRTC DataChannels for low-latency game data. Features authentication, users, lobbies, groups, parties, friends, chat, notifications, achievements, leaderboards, tournaments, matchmaking, payments, server scripting, and admin portal.  ## **1. Authentication**  This API uses JWT (JSON Web Tokens) with access and refresh tokens:  ### **1.1 Getting Tokens** - **Email/Password**: POST to `/api/v1/login` with email and password - **Device (SDK)**: POST to `/api/v1/login` with a `device_id` string (creates/returns a device user) - **Discord OAuth**: Use `/api/v1/auth/discord` flow - **Google OAuth**: Use `/api/v1/auth/google` flow - **Facebook OAuth**: Use `/api/v1/auth/facebook` flow - **Apple Sign In**: Use `/auth/apple` browser flow or apple sdk flow - **Steam (OpenID)**: Use `/api/v1/auth/steam` flow  Both methods return: - `access_token` - Short-lived (15 min), use for API requests - `refresh_token` - Long-lived (30 days), use to get new access tokens  ### **1.2 Using Tokens** Include the access token in the Authorization header: ``` Authorization: Bearer <access_token> ```  ### **1.3 Refreshing Tokens** When your access token expires, use POST `/api/v1/refresh` with your refresh token to get a new access token.  ## **2. Users** Users endpoints cover the user lifecycle and profile features. Key highlights:  - **Registration and login** (email/password, device token for SDKs, and OAuth providers) - **Profile metadata** (JSON blob per user) and editable profile fields - **Account lifecycle**: password reset, email confirmation, and account deletion - **Sessions & tokens**: both browser sessions and JWT-based API tokens are supported  ## **3. Friends** The Friends domain offers lightweight social features:  - **Friend requests** (send / accept / reject / block flows) - **Friend listing & pagination**, with basic privacy controls - **Domain helpers** to manage and query friend relationships from API or UI contexts  ## **4. Lobbies** Lobbies provide matchmaking / room management primitives. Highlights:  - **Create / list / update / delete** lobbies with rich metadata (mode, region, tags) - **Host-managed or hostless** modes (hostless allowed internally, not creatable via public API) - **Membership management**: join, leave, kick users, and automatic host transfer - **Controls & protection**: max users, hidden/locked states, and optional password protection - **Hidden lobbies** are excluded from public listings; public listing endpoints are paginated  ## **5. Notifications** Persistent user-to-user notifications that survive across sessions:  - **Send notifications** to accepted friends with a title, optional content, and optional metadata - **List own notifications** with pagination (ordered oldest-first) - **Delete notifications** by ID (single or batch) - **Real-time delivery** via the user WebSocket channel (`\"notification\"` events) - **Offline delivery**: undeleted notifications are replayed on WebSocket reconnect  ## **6. Groups** Groups provide persistent community management for players:  - **Three group types**: `public` (anyone joins directly), `private` (users request to join, admins approve), `hidden` (invite-only, never listed) - **Membership roles**: `admin` and `member`, with promote/demote capabilities - **Join requests**: for private groups, users submit requests that admins approve or reject - **Invitations**: admins can invite users directly (blocked users are rejected) - **CRUD operations**: create, update, delete groups with metadata support - **Group chat**: integrated via the Chat API with `chat_type: \"group\"`  ## **7. Parties** Ephemeral groups of users for short-lived sessions (e.g., matchmaking squads):  - **Invite-only joining**: the party leader sends invites by user ID to friends or shared-group members - **Invite flow**: `POST /parties/invite` → recipient accepts via `POST /parties/invite/accept` or declines via `POST /parties/invite/decline`; leader can cancel via `POST /parties/invite/cancel` - **Invite visibility**: leader can list sent invites (`GET /parties/invitations/sent`); recipient can list received invites (`GET /parties/invitations`) - **Connection requirement**: invites can only be sent to users who are friends or share at least one group with the leader - **One party at a time**: a user can only be in one party; accepting an invite while already in a party is rejected - **Leader management**: the creator is the leader; leadership can be transferred - **Lobby integration**: parties can create or join lobbies as a group - **Party chat**: integrated via the Chat API with `chat_type: \"party\"` - **Real-time events** via the party WebSocket channel  ## **8. Chat** Real-time messaging across multiple conversation types:  - **Chat types**: `lobby` (within a lobby), `group` (within a group), `party` (within a party), `friend` (DMs between friends) - **Send messages** with content, optional metadata, and automatic access validation - **List messages** with pagination (newest first) - **Read tracking**: mark messages as read and get unread counts per conversation - **Real-time delivery** via PubSub and WebSocket channels - **Moderation hooks**: `before_chat_message` pipeline hook for filtering/blocking  ## **9. Leaderboards** Server-managed ranked scoreboards:  - **Multiple leaderboards**: create named leaderboards with configurable sort order - **Score submission**: submit scores with optional metadata - **Rankings**: retrieve paginated rankings with user details - **Reset support**: leaderboards can be reset periodically  ## **10. Key-Value Storage** Per-user persistent key-value storage for game state, preferences, and settings:  - **Get/set/delete** key-value pairs scoped to the authenticated user - **List keys** with optional prefix filtering - **Metadata support**: values can include arbitrary JSON metadata  ## **11. Achievements** Track player accomplishments with progress-based or instant-unlock achievements:  - **Achievement definitions**: admin-created with slug, title, description, icon, sort order, and optional progress target - **Progress tracking**: increment progress toward a target; auto-unlocks when progress reaches the target - **Instant unlock**: directly unlock achievements without progress tracking - **Hidden achievements**: details obscured (\"???\") until unlocked by the user - **Public listings**: paginated, optionally filtered; authenticated users see their own progress - **Admin management**: create, update, delete, grant, revoke, unlock, and increment achievements  ## **12. Tournaments** Single-elimination bracket tournaments, server-structured and game-judged:  - **Registration window → seeded draw → timed rounds → champions**; recurring tournaments (cron) create one occurrence per cycle sharing a slug; a nil starts_at keeps registration open until an admin draws manually - **Join/leave** as an entry leader (`POST`/`DELETE /tournaments/:id/join`); team composition is game policy - **Browse**: list/filter tournaments, standings, full bracket view, and the caller's current match (`GET /tournaments/:id/my-match`) - **Match verdicts are server-side** (game hooks) — no public resolve endpoint; clients get `tournament_match_ready` / `tournament_match_resolved` / `tournament_updated` / `tournament_finished` on the user channel - **Admin management** over HTTP: create/update/delete, cancel, draw now, finish, and force match verdicts under `/api/v1/admin/tournaments`  ## **13. Matchmaking** Ticket-based queueing that turns waiting players into hidden, locked lobbies:  - **Join over HTTP** (`POST /matchmaking/tickets` with a `match_params` string map); only tickets with identical params match together — encode mode/map/skill band as parameter values - **A match forms** when a group reaches `max_players`, or has at least `min_players` and the oldest ticket outwaited the timeout; the server creates a hidden lobby, seats everyone and locks it - **The result is a push, not a poll**: matched players receive `match_found` (`lobby_id`, `match_params`) on their user channel; disconnecting cancels your tickets - **Inspect**: `GET /matchmaking/tickets/me` for your ticket, `GET /matchmaking/stats` for queue depths - **Admin management** over HTTP: list/filter tickets, force-cancel, and stats under `/api/v1/admin/matchmaking`  ## **14. Real-time: WebSocket Channels** The server provides real-time communication via Phoenix WebSocket channels. Connect to the WebSocket endpoint and join topic-based channels for live updates.  ### **14.1 Connection** Connect to `wss://your-server.com/socket` with your JWT token as a parameter: ``` const socket = new Socket(\"wss://your-server.com/socket\", { params: { token: \"<access_token>\" } }) socket.connect() ```  ### **14.2 Available Channels** - **User channel** (`user:<user_id>`): notifications, friend events, achievement unlocks, party/group invites, tournament events, KV subscriptions - **Lobby channel** (`lobby:<lobby_id>`): lobby member joins/leaves, lobby updates, lobby chat - **Lobbies channel** (`lobbies`): global lobby list changes (created, updated, deleted) - **Group channel** (`group:<group_id>`): group member changes, group updates, group chat - **Groups channel** (`groups`): global group list changes - **Party channel** (`party:<party_id>`): party member changes, party updates, party chat  ### **14.3 JS SDK Helper** The `GameRealtime` class (included in this SDK) wraps Phoenix.Socket with convenient channel helpers: ```javascript import { GameRealtime } from '@ughuuu/game_server' const realtime = new GameRealtime('https://your-server.com', accessToken) const userChannel = realtime.joinUserChannel(userId) userChannel.on('notification', payload => console.log(payload)) ``` Requires the `phoenix` npm package as a peer dependency: `npm install phoenix`  ## **15. Real-time: WebRTC DataChannels** For low-latency game data, the server supports WebRTC DataChannels alongside WebSocket. The server acts as a WebRTC peer (not P2P between clients).  ### **15.1 How It Works** 1. Client connects via WebSocket and joins the **User channel** 2. Client sends an SDP offer over the channel (`webrtc:offer` event) 3. Server responds with an SDP answer (`webrtc:answer` event) 4. ICE candidates are exchanged (`webrtc:ice` events) 5. Once connected, named DataChannels carry game data at low latency  ### **15.2 Default DataChannels** - **`events`** (reliable, ordered): important game events (player actions, state changes) - **`state`** (unreliable, unordered): high-frequency position/state sync  ### **15.3 JS SDK Helper** The `GameWebRTC` class (included in this SDK, browser-only) handles signaling automatically: ```javascript import { GameRealtime, GameWebRTC } from '@ughuuu/game_server' const realtime = new GameRealtime('https://your-server.com', token) const userChannel = realtime.joinUserChannel(userId) const webrtc = new GameWebRTC(userChannel, {   onData: (label, data) => console.log(label, data) }) await webrtc.connect() webrtc.send('events', JSON.stringify({ type: 'move', x: 10, y: 20 })) ``` 
+ * API for the Gamend Game Server. Provides HTTP REST API, real-time WebSocket channels, and WebRTC DataChannels for low-latency game data. Features authentication, users, lobbies, groups, parties, friends, chat, notifications, quests, leaderboards, tournaments, matchmaking, payments, server scripting, and admin portal.  ## **1. Authentication**  This API uses JWT (JSON Web Tokens) with access and refresh tokens:  ### **1.1 Getting Tokens** - **Email/Password**: POST to `/api/v1/login` with email and password - **Device (SDK)**: POST to `/api/v1/login` with a `device_id` string (creates/returns a device user) - **Discord OAuth**: Use `/api/v1/auth/discord` flow - **Google OAuth**: Use `/api/v1/auth/google` flow - **Facebook OAuth**: Use `/api/v1/auth/facebook` flow - **Apple Sign In**: Use `/auth/apple` browser flow or apple sdk flow - **Steam (OpenID)**: Use `/api/v1/auth/steam` flow  Both methods return: - `access_token` - Short-lived (15 min), use for API requests - `refresh_token` - Long-lived (30 days), use to get new access tokens  ### **1.2 Using Tokens** Include the access token in the Authorization header: ``` Authorization: Bearer <access_token> ```  ### **1.3 Refreshing Tokens** When your access token expires, use POST `/api/v1/refresh` with your refresh token to get a new access token.  ## **2. Users** Users endpoints cover the user lifecycle and profile features. Key highlights:  - **Registration and login** (email/password, device token for SDKs, and OAuth providers) - **Profile metadata** (JSON blob per user) and editable profile fields - **Account lifecycle**: password reset, email confirmation, and account deletion - **Sessions & tokens**: both browser sessions and JWT-based API tokens are supported  ## **3. Friends** The Friends domain offers lightweight social features:  - **Friend requests** (send / accept / reject / block flows) - **Friend listing & pagination**, with basic privacy controls - **Domain helpers** to manage and query friend relationships from API or UI contexts  ## **4. Lobbies** Lobbies provide matchmaking / room management primitives. Highlights:  - **Create / list / update / delete** lobbies with rich metadata (mode, region, tags) - **Host-managed or hostless** modes (hostless allowed internally, not creatable via public API) - **Membership management**: join, leave, kick users, and automatic host transfer - **Controls & protection**: max users, hidden/locked states, and optional password protection - **Hidden lobbies** are excluded from public listings; public listing endpoints are paginated  ## **5. Notifications** Persistent user-to-user notifications that survive across sessions:  - **Send notifications** to accepted friends with a title, optional content, and optional metadata - **List own notifications** with pagination (ordered oldest-first) - **Delete notifications** by ID (single or batch) - **Real-time delivery** via the user WebSocket channel (`\"notification\"` events) - **Offline delivery**: undeleted notifications are replayed on WebSocket reconnect - **Push delivery**: notifications also fan out to the recipient's registered mobile devices (see Push notifications)  ## **5b. Push notifications** Mobile/web push delivery to registered devices (FCM for Android/Web, APNs-direct for iOS):  - **Register device tokens** via `POST /me/push-tokens` (`token`, `platform`, optional `provider`/`device_id`); re-registering a `device_id` rotates its token in place - **List/remove own devices** via `GET /me/push-tokens` and `DELETE /me/push-tokens/:id` - **Server-authoritative sending** — no public send endpoint; pushes originate from server hooks (`GameServer.Push.send_to_user/2`) or the admin API - **Per-token routing**: each token's `provider` (\"fcm\" | \"apns\") selects the delivery backend; unconfigured backends log instead of sending (dev-friendly) - **Reliability**: delivery rides the durable job queue with retries; dead tokens reported by the provider are disabled automatically  ## **6. Groups** Groups provide persistent community management for players:  - **Three group types**: `public` (anyone joins directly), `private` (users request to join, admins approve), `hidden` (invite-only, never listed) - **Membership roles**: `admin` and `member`, with promote/demote capabilities - **Join requests**: for private groups, users submit requests that admins approve or reject - **Invitations**: admins can invite users directly (blocked users are rejected) - **CRUD operations**: create, update, delete groups with metadata support - **Group chat**: integrated via the Chat API with `chat_type: \"group\"`  ## **7. Parties** Ephemeral groups of users for short-lived sessions (e.g., matchmaking squads):  - **Invite-only joining**: the party leader sends invites by user ID to friends or shared-group members - **Invite flow**: `POST /parties/invite` → recipient accepts via `POST /parties/invite/accept` or declines via `POST /parties/invite/decline`; leader can cancel via `POST /parties/invite/cancel` - **Invite visibility**: leader can list sent invites (`GET /parties/invitations/sent`); recipient can list received invites (`GET /parties/invitations`) - **Connection requirement**: invites can only be sent to users who are friends or share at least one group with the leader - **One party at a time**: a user can only be in one party; accepting an invite while already in a party is rejected - **Leader management**: the creator is the leader; leadership can be transferred - **Lobby integration**: parties can create or join lobbies as a group - **Party chat**: integrated via the Chat API with `chat_type: \"party\"` - **Real-time events** via the party WebSocket channel  ## **8. Chat** Real-time messaging across multiple conversation types:  - **Chat types**: `lobby` (within a lobby), `group` (within a group), `party` (within a party), `friend` (DMs between friends) - **Send messages** with content, optional metadata, and automatic access validation - **List messages** with pagination (newest first) - **Read tracking**: mark messages as read and get unread counts per conversation - **Real-time delivery** via PubSub and WebSocket channels - **Moderation hooks**: `before_chat_message` pipeline hook for filtering/blocking  ## **9. Leaderboards** Server-managed ranked scoreboards:  - **Multiple leaderboards**: create named leaderboards with configurable sort order - **Score submission**: submit scores with optional metadata - **Rankings**: retrieve paginated rankings with user details - **Reset support**: leaderboards can be reset periodically  ## **10. Key-Value Storage** Per-user persistent key-value storage for game state, preferences, and settings:  - **Get/set/delete** key-value pairs scoped to the authenticated user - **List keys** with optional prefix filtering - **Metadata support**: values can include arbitrary JSON metadata  ## **11. Quests / Progression** One event-driven progression engine covering achievements, daily/weekly quests, time-boxed event quests, and chains:  - **Kinds**: `achievement` (permanent one-shot — the replacement for the old achievements system), `daily`/`weekly` (reset per UTC period), `event` (starts_at/ends_at window), `chain` (requires a prerequisite quest) - **Objectives**: each quest lists objectives `{event, target, params}`; server-side `report_event` advances every matching active quest — there is **no public endpoint to advance progress** (server-authoritative) - **Rewards**: currencies (Economy) and items (Inventory), paid **exactly once** per period via idempotent grants; `auto_claim` quests pay on completion, others via `POST /me/quests/:key/claim` - **My quests**: `GET /me/quests` returns active quests, per-period progress, and a claimable flag; hidden quests appear once completed - **Catalog**: `GET /quests` and per-user completions `GET /quests/user/:user_id` (gated by `LIST_QUESTS_ENABLED`) - **Admin management**: definitions CRUD plus per-user grant/reset/force-claim under `/api/v1/admin/quests`  ## **12. Tournaments** Single-elimination bracket tournaments, server-structured and game-judged:  - **Registration window → seeded draw → timed rounds → champions**; recurring tournaments (cron) create one occurrence per cycle sharing a slug; a nil starts_at keeps registration open until an admin draws manually - **Join/leave** as an entry leader (`POST`/`DELETE /tournaments/:id/join`); team composition is game policy - **Browse**: list/filter tournaments, standings, full bracket view, and the caller's current match (`GET /tournaments/:id/my-match`) - **Match verdicts are server-side** (game hooks) — no public resolve endpoint; clients get `tournament_match_ready` / `tournament_match_resolved` / `tournament_updated` / `tournament_finished` on the user channel - **Admin management** over HTTP: create/update/delete, cancel, draw now, finish, and force match verdicts under `/api/v1/admin/tournaments`  ## **13. Matchmaking** Ticket-based queueing that turns waiting players into hidden, locked lobbies:  - **Join over HTTP** (`POST /matchmaking/tickets` with a `match_params` string map); only tickets with identical params match together — encode mode/map/skill band as parameter values - **A match forms** when a group reaches `max_players`, or has at least `min_players` and the oldest ticket outwaited the timeout; the server creates a hidden lobby, seats everyone and locks it - **The result is a push, not a poll**: matched players receive `match_found` (`lobby_id`, `match_params`) on their user channel; disconnecting cancels your tickets - **Inspect**: `GET /matchmaking/tickets/me` for your ticket, `GET /matchmaking/stats` for queue depths - **Admin management** over HTTP: list/filter tickets, force-cancel, and stats under `/api/v1/admin/matchmaking`  ## **14. Ready checks** One primitive for \"everyone must answer before this proceeds\", with one client-facing surface:  - **A player holds at most one check per lane** — the match lane (lobby ready-up or matchmaking accept) and the party lane (the party's standing board) — so answering needs no id: `GET /me/ready_check` returns `{\"lobby\": …, \"party\": …}` (each null when none) and `POST /me/ready_check` with `{\"ready\": true|false, \"scope\": \"lobby\"|\"party\"}` answers one (scope defaults to `lobby`) - **Two kinds.** `ready` (lobby/party board) is a toggle — a \"no\" just leaves the check open, and it lists every participant. `accept` (match confirmation) is final — one decline fails it for everyone — and returns counts plus your own state, so a pending match does not reveal who you were paired with - **Hosts open one** with `POST /lobbies/ready_check` (host-managed lobbies only; hostless matchmaking lobbies belong to the server), **party leaders** with `POST /parties/ready_check`; either call is a **reset** — it quietly replaces an already-open board with a fresh one over the current members, so the same endpoint serves \"ready check!\", \"force ready\" (with `timeout_ms`) and \"start over\". Call it off with `DELETE /lobbies/ready_check` / `DELETE /parties/ready_check`. The opener is pre-marked ready — clicking the button is their answer - **Failure does nothing on its own**: a declined or timed-out check kicks nobody, starts nothing, and moves no lobby state. It reports who did not answer, and the game (or the host, with the kick they already have) decides - **Live**: `ready_check_started` / `ready_check_updated` / `ready_check_passed` / `ready_check_failed` on the lobby channel, the party channel for a party board, or the user channel for an accept check - **Admin management** over HTTP: list/filter checks, force-cancel, and 24h outcome stats under `/api/v1/admin/ready_checks`  ## **15. Real-time: WebSocket Channels** The server provides real-time communication via Phoenix WebSocket channels. Connect to the WebSocket endpoint and join topic-based channels for live updates.  ### **15.1 Connection** Connect to `wss://your-server.com/socket` with your JWT token as a parameter: ``` const socket = new Socket(\"wss://your-server.com/socket\", { params: { token: \"<access_token>\" } }) socket.connect() ```  ### **15.2 Available Channels** - **User channel** (`user:<user_id>`): notifications, friend events, quest progress/completions/claims, party/group invites, tournament events, KV subscriptions - **Lobby channel** (`lobby:<lobby_id>`): lobby member joins/leaves, lobby updates, lobby chat - **Lobbies channel** (`lobbies`): global lobby list changes (created, updated, deleted) - **Group channel** (`group:<group_id>`): group member changes, group updates, group chat - **Groups channel** (`groups`): global group list changes - **Party channel** (`party:<party_id>`): party member changes, party updates, party chat  ### **15.3 JS SDK Helper** The `GameRealtime` class (included in this SDK) wraps Phoenix.Socket with convenient channel helpers: ```javascript import { GameRealtime } from '@ughuuu/game_server' const realtime = new GameRealtime('https://your-server.com', accessToken) const userChannel = realtime.joinUserChannel(userId) userChannel.on('notification', payload => console.log(payload)) ``` Requires the `phoenix` npm package as a peer dependency: `npm install phoenix`  ## **16. Real-time: WebRTC DataChannels** For low-latency game data, the server supports WebRTC DataChannels alongside WebSocket. The server acts as a WebRTC peer (not P2P between clients).  ### **16.1 How It Works** 1. Client connects via WebSocket and joins the **User channel** 2. Client sends an SDP offer over the channel (`webrtc:offer` event) 3. Server responds with an SDP answer (`webrtc:answer` event) 4. ICE candidates are exchanged (`webrtc:ice` events) 5. Once connected, named DataChannels carry game data at low latency  ### **16.2 Default DataChannels** - **`events`** (reliable, ordered): important game events (player actions, state changes) - **`state`** (unreliable, unordered): high-frequency position/state sync  ### **16.3 JS SDK Helper** The `GameWebRTC` class (included in this SDK, browser-only) handles signaling automatically: ```javascript import { GameRealtime, GameWebRTC } from '@ughuuu/game_server' const realtime = new GameRealtime('https://your-server.com', token) const userChannel = realtime.joinUserChannel(userId) const webrtc = new GameWebRTC(userChannel, {   onData: (label, data) => console.log(label, data) }) await webrtc.connect() webrtc.send('events', JSON.stringify({ type: 'move', x: 10, y: 20 })) ``` 
  *
- * The version of the OpenAPI document: 1.0.1059
+ * The version of the OpenAPI document: 1.0.1070
  * 
  *
  * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).

package/dist/api/AdminChatApi.js

@@ -16,9 +16,9 @@ function _createClass(e, r, t) { return r && _defineProperties(e.prototype, r),
 function _toPropertyKey(t) { var i = _toPrimitive(t, "string"); return "symbol" == _typeof(i) ? i : i + ""; }
 function _toPrimitive(t, r) { if ("object" != _typeof(t) || !t) return t; var e = t[Symbol.toPrimitive]; if (void 0 !== e) { var i = e.call(t, r || "default"); if ("object" != _typeof(i)) return i; throw new TypeError("@@toPrimitive must return a primitive value."); } return ("string" === r ? String : Number)(t); } /**
  * Game Server API
- * API for the Gamend Game Server. Provides HTTP REST API, real-time WebSocket channels, and WebRTC DataChannels for low-latency game data. Features authentication, users, lobbies, groups, parties, friends, chat, notifications, achievements, leaderboards, tournaments, matchmaking, payments, server scripting, and admin portal.  ## **1. Authentication**  This API uses JWT (JSON Web Tokens) with access and refresh tokens:  ### **1.1 Getting Tokens** - **Email/Password**: POST to `/api/v1/login` with email and password - **Device (SDK)**: POST to `/api/v1/login` with a `device_id` string (creates/returns a device user) - **Discord OAuth**: Use `/api/v1/auth/discord` flow - **Google OAuth**: Use `/api/v1/auth/google` flow - **Facebook OAuth**: Use `/api/v1/auth/facebook` flow - **Apple Sign In**: Use `/auth/apple` browser flow or apple sdk flow - **Steam (OpenID)**: Use `/api/v1/auth/steam` flow  Both methods return: - `access_token` - Short-lived (15 min), use for API requests - `refresh_token` - Long-lived (30 days), use to get new access tokens  ### **1.2 Using Tokens** Include the access token in the Authorization header: ``` Authorization: Bearer <access_token> ```  ### **1.3 Refreshing Tokens** When your access token expires, use POST `/api/v1/refresh` with your refresh token to get a new access token.  ## **2. Users** Users endpoints cover the user lifecycle and profile features. Key highlights:  - **Registration and login** (email/password, device token for SDKs, and OAuth providers) - **Profile metadata** (JSON blob per user) and editable profile fields - **Account lifecycle**: password reset, email confirmation, and account deletion - **Sessions & tokens**: both browser sessions and JWT-based API tokens are supported  ## **3. Friends** The Friends domain offers lightweight social features:  - **Friend requests** (send / accept / reject / block flows) - **Friend listing & pagination**, with basic privacy controls - **Domain helpers** to manage and query friend relationships from API or UI contexts  ## **4. Lobbies** Lobbies provide matchmaking / room management primitives. Highlights:  - **Create / list / update / delete** lobbies with rich metadata (mode, region, tags) - **Host-managed or hostless** modes (hostless allowed internally, not creatable via public API) - **Membership management**: join, leave, kick users, and automatic host transfer - **Controls & protection**: max users, hidden/locked states, and optional password protection - **Hidden lobbies** are excluded from public listings; public listing endpoints are paginated  ## **5. Notifications** Persistent user-to-user notifications that survive across sessions:  - **Send notifications** to accepted friends with a title, optional content, and optional metadata - **List own notifications** with pagination (ordered oldest-first) - **Delete notifications** by ID (single or batch) - **Real-time delivery** via the user WebSocket channel (`\"notification\"` events) - **Offline delivery**: undeleted notifications are replayed on WebSocket reconnect  ## **6. Groups** Groups provide persistent community management for players:  - **Three group types**: `public` (anyone joins directly), `private` (users request to join, admins approve), `hidden` (invite-only, never listed) - **Membership roles**: `admin` and `member`, with promote/demote capabilities - **Join requests**: for private groups, users submit requests that admins approve or reject - **Invitations**: admins can invite users directly (blocked users are rejected) - **CRUD operations**: create, update, delete groups with metadata support - **Group chat**: integrated via the Chat API with `chat_type: \"group\"`  ## **7. Parties** Ephemeral groups of users for short-lived sessions (e.g., matchmaking squads):  - **Invite-only joining**: the party leader sends invites by user ID to friends or shared-group members - **Invite flow**: `POST /parties/invite` → recipient accepts via `POST /parties/invite/accept` or declines via `POST /parties/invite/decline`; leader can cancel via `POST /parties/invite/cancel` - **Invite visibility**: leader can list sent invites (`GET /parties/invitations/sent`); recipient can list received invites (`GET /parties/invitations`) - **Connection requirement**: invites can only be sent to users who are friends or share at least one group with the leader - **One party at a time**: a user can only be in one party; accepting an invite while already in a party is rejected - **Leader management**: the creator is the leader; leadership can be transferred - **Lobby integration**: parties can create or join lobbies as a group - **Party chat**: integrated via the Chat API with `chat_type: \"party\"` - **Real-time events** via the party WebSocket channel  ## **8. Chat** Real-time messaging across multiple conversation types:  - **Chat types**: `lobby` (within a lobby), `group` (within a group), `party` (within a party), `friend` (DMs between friends) - **Send messages** with content, optional metadata, and automatic access validation - **List messages** with pagination (newest first) - **Read tracking**: mark messages as read and get unread counts per conversation - **Real-time delivery** via PubSub and WebSocket channels - **Moderation hooks**: `before_chat_message` pipeline hook for filtering/blocking  ## **9. Leaderboards** Server-managed ranked scoreboards:  - **Multiple leaderboards**: create named leaderboards with configurable sort order - **Score submission**: submit scores with optional metadata - **Rankings**: retrieve paginated rankings with user details - **Reset support**: leaderboards can be reset periodically  ## **10. Key-Value Storage** Per-user persistent key-value storage for game state, preferences, and settings:  - **Get/set/delete** key-value pairs scoped to the authenticated user - **List keys** with optional prefix filtering - **Metadata support**: values can include arbitrary JSON metadata  ## **11. Achievements** Track player accomplishments with progress-based or instant-unlock achievements:  - **Achievement definitions**: admin-created with slug, title, description, icon, sort order, and optional progress target - **Progress tracking**: increment progress toward a target; auto-unlocks when progress reaches the target - **Instant unlock**: directly unlock achievements without progress tracking - **Hidden achievements**: details obscured (\"???\") until unlocked by the user - **Public listings**: paginated, optionally filtered; authenticated users see their own progress - **Admin management**: create, update, delete, grant, revoke, unlock, and increment achievements  ## **12. Tournaments** Single-elimination bracket tournaments, server-structured and game-judged:  - **Registration window → seeded draw → timed rounds → champions**; recurring tournaments (cron) create one occurrence per cycle sharing a slug; a nil starts_at keeps registration open until an admin draws manually - **Join/leave** as an entry leader (`POST`/`DELETE /tournaments/:id/join`); team composition is game policy - **Browse**: list/filter tournaments, standings, full bracket view, and the caller's current match (`GET /tournaments/:id/my-match`) - **Match verdicts are server-side** (game hooks) — no public resolve endpoint; clients get `tournament_match_ready` / `tournament_match_resolved` / `tournament_updated` / `tournament_finished` on the user channel - **Admin management** over HTTP: create/update/delete, cancel, draw now, finish, and force match verdicts under `/api/v1/admin/tournaments`  ## **13. Matchmaking** Ticket-based queueing that turns waiting players into hidden, locked lobbies:  - **Join over HTTP** (`POST /matchmaking/tickets` with a `match_params` string map); only tickets with identical params match together — encode mode/map/skill band as parameter values - **A match forms** when a group reaches `max_players`, or has at least `min_players` and the oldest ticket outwaited the timeout; the server creates a hidden lobby, seats everyone and locks it - **The result is a push, not a poll**: matched players receive `match_found` (`lobby_id`, `match_params`) on their user channel; disconnecting cancels your tickets - **Inspect**: `GET /matchmaking/tickets/me` for your ticket, `GET /matchmaking/stats` for queue depths - **Admin management** over HTTP: list/filter tickets, force-cancel, and stats under `/api/v1/admin/matchmaking`  ## **14. Real-time: WebSocket Channels** The server provides real-time communication via Phoenix WebSocket channels. Connect to the WebSocket endpoint and join topic-based channels for live updates.  ### **14.1 Connection** Connect to `wss://your-server.com/socket` with your JWT token as a parameter: ``` const socket = new Socket(\"wss://your-server.com/socket\", { params: { token: \"<access_token>\" } }) socket.connect() ```  ### **14.2 Available Channels** - **User channel** (`user:<user_id>`): notifications, friend events, achievement unlocks, party/group invites, tournament events, KV subscriptions - **Lobby channel** (`lobby:<lobby_id>`): lobby member joins/leaves, lobby updates, lobby chat - **Lobbies channel** (`lobbies`): global lobby list changes (created, updated, deleted) - **Group channel** (`group:<group_id>`): group member changes, group updates, group chat - **Groups channel** (`groups`): global group list changes - **Party channel** (`party:<party_id>`): party member changes, party updates, party chat  ### **14.3 JS SDK Helper** The `GameRealtime` class (included in this SDK) wraps Phoenix.Socket with convenient channel helpers: ```javascript import { GameRealtime } from '@ughuuu/game_server' const realtime = new GameRealtime('https://your-server.com', accessToken) const userChannel = realtime.joinUserChannel(userId) userChannel.on('notification', payload => console.log(payload)) ``` Requires the `phoenix` npm package as a peer dependency: `npm install phoenix`  ## **15. Real-time: WebRTC DataChannels** For low-latency game data, the server supports WebRTC DataChannels alongside WebSocket. The server acts as a WebRTC peer (not P2P between clients).  ### **15.1 How It Works** 1. Client connects via WebSocket and joins the **User channel** 2. Client sends an SDP offer over the channel (`webrtc:offer` event) 3. Server responds with an SDP answer (`webrtc:answer` event) 4. ICE candidates are exchanged (`webrtc:ice` events) 5. Once connected, named DataChannels carry game data at low latency  ### **15.2 Default DataChannels** - **`events`** (reliable, ordered): important game events (player actions, state changes) - **`state`** (unreliable, unordered): high-frequency position/state sync  ### **15.3 JS SDK Helper** The `GameWebRTC` class (included in this SDK, browser-only) handles signaling automatically: ```javascript import { GameRealtime, GameWebRTC } from '@ughuuu/game_server' const realtime = new GameRealtime('https://your-server.com', token) const userChannel = realtime.joinUserChannel(userId) const webrtc = new GameWebRTC(userChannel, {   onData: (label, data) => console.log(label, data) }) await webrtc.connect() webrtc.send('events', JSON.stringify({ type: 'move', x: 10, y: 20 })) ``` 
+ * API for the Gamend Game Server. Provides HTTP REST API, real-time WebSocket channels, and WebRTC DataChannels for low-latency game data. Features authentication, users, lobbies, groups, parties, friends, chat, notifications, quests, leaderboards, tournaments, matchmaking, payments, server scripting, and admin portal.  ## **1. Authentication**  This API uses JWT (JSON Web Tokens) with access and refresh tokens:  ### **1.1 Getting Tokens** - **Email/Password**: POST to `/api/v1/login` with email and password - **Device (SDK)**: POST to `/api/v1/login` with a `device_id` string (creates/returns a device user) - **Discord OAuth**: Use `/api/v1/auth/discord` flow - **Google OAuth**: Use `/api/v1/auth/google` flow - **Facebook OAuth**: Use `/api/v1/auth/facebook` flow - **Apple Sign In**: Use `/auth/apple` browser flow or apple sdk flow - **Steam (OpenID)**: Use `/api/v1/auth/steam` flow  Both methods return: - `access_token` - Short-lived (15 min), use for API requests - `refresh_token` - Long-lived (30 days), use to get new access tokens  ### **1.2 Using Tokens** Include the access token in the Authorization header: ``` Authorization: Bearer <access_token> ```  ### **1.3 Refreshing Tokens** When your access token expires, use POST `/api/v1/refresh` with your refresh token to get a new access token.  ## **2. Users** Users endpoints cover the user lifecycle and profile features. Key highlights:  - **Registration and login** (email/password, device token for SDKs, and OAuth providers) - **Profile metadata** (JSON blob per user) and editable profile fields - **Account lifecycle**: password reset, email confirmation, and account deletion - **Sessions & tokens**: both browser sessions and JWT-based API tokens are supported  ## **3. Friends** The Friends domain offers lightweight social features:  - **Friend requests** (send / accept / reject / block flows) - **Friend listing & pagination**, with basic privacy controls - **Domain helpers** to manage and query friend relationships from API or UI contexts  ## **4. Lobbies** Lobbies provide matchmaking / room management primitives. Highlights:  - **Create / list / update / delete** lobbies with rich metadata (mode, region, tags) - **Host-managed or hostless** modes (hostless allowed internally, not creatable via public API) - **Membership management**: join, leave, kick users, and automatic host transfer - **Controls & protection**: max users, hidden/locked states, and optional password protection - **Hidden lobbies** are excluded from public listings; public listing endpoints are paginated  ## **5. Notifications** Persistent user-to-user notifications that survive across sessions:  - **Send notifications** to accepted friends with a title, optional content, and optional metadata - **List own notifications** with pagination (ordered oldest-first) - **Delete notifications** by ID (single or batch) - **Real-time delivery** via the user WebSocket channel (`\"notification\"` events) - **Offline delivery**: undeleted notifications are replayed on WebSocket reconnect - **Push delivery**: notifications also fan out to the recipient's registered mobile devices (see Push notifications)  ## **5b. Push notifications** Mobile/web push delivery to registered devices (FCM for Android/Web, APNs-direct for iOS):  - **Register device tokens** via `POST /me/push-tokens` (`token`, `platform`, optional `provider`/`device_id`); re-registering a `device_id` rotates its token in place - **List/remove own devices** via `GET /me/push-tokens` and `DELETE /me/push-tokens/:id` - **Server-authoritative sending** — no public send endpoint; pushes originate from server hooks (`GameServer.Push.send_to_user/2`) or the admin API - **Per-token routing**: each token's `provider` (\"fcm\" | \"apns\") selects the delivery backend; unconfigured backends log instead of sending (dev-friendly) - **Reliability**: delivery rides the durable job queue with retries; dead tokens reported by the provider are disabled automatically  ## **6. Groups** Groups provide persistent community management for players:  - **Three group types**: `public` (anyone joins directly), `private` (users request to join, admins approve), `hidden` (invite-only, never listed) - **Membership roles**: `admin` and `member`, with promote/demote capabilities - **Join requests**: for private groups, users submit requests that admins approve or reject - **Invitations**: admins can invite users directly (blocked users are rejected) - **CRUD operations**: create, update, delete groups with metadata support - **Group chat**: integrated via the Chat API with `chat_type: \"group\"`  ## **7. Parties** Ephemeral groups of users for short-lived sessions (e.g., matchmaking squads):  - **Invite-only joining**: the party leader sends invites by user ID to friends or shared-group members - **Invite flow**: `POST /parties/invite` → recipient accepts via `POST /parties/invite/accept` or declines via `POST /parties/invite/decline`; leader can cancel via `POST /parties/invite/cancel` - **Invite visibility**: leader can list sent invites (`GET /parties/invitations/sent`); recipient can list received invites (`GET /parties/invitations`) - **Connection requirement**: invites can only be sent to users who are friends or share at least one group with the leader - **One party at a time**: a user can only be in one party; accepting an invite while already in a party is rejected - **Leader management**: the creator is the leader; leadership can be transferred - **Lobby integration**: parties can create or join lobbies as a group - **Party chat**: integrated via the Chat API with `chat_type: \"party\"` - **Real-time events** via the party WebSocket channel  ## **8. Chat** Real-time messaging across multiple conversation types:  - **Chat types**: `lobby` (within a lobby), `group` (within a group), `party` (within a party), `friend` (DMs between friends) - **Send messages** with content, optional metadata, and automatic access validation - **List messages** with pagination (newest first) - **Read tracking**: mark messages as read and get unread counts per conversation - **Real-time delivery** via PubSub and WebSocket channels - **Moderation hooks**: `before_chat_message` pipeline hook for filtering/blocking  ## **9. Leaderboards** Server-managed ranked scoreboards:  - **Multiple leaderboards**: create named leaderboards with configurable sort order - **Score submission**: submit scores with optional metadata - **Rankings**: retrieve paginated rankings with user details - **Reset support**: leaderboards can be reset periodically  ## **10. Key-Value Storage** Per-user persistent key-value storage for game state, preferences, and settings:  - **Get/set/delete** key-value pairs scoped to the authenticated user - **List keys** with optional prefix filtering - **Metadata support**: values can include arbitrary JSON metadata  ## **11. Quests / Progression** One event-driven progression engine covering achievements, daily/weekly quests, time-boxed event quests, and chains:  - **Kinds**: `achievement` (permanent one-shot — the replacement for the old achievements system), `daily`/`weekly` (reset per UTC period), `event` (starts_at/ends_at window), `chain` (requires a prerequisite quest) - **Objectives**: each quest lists objectives `{event, target, params}`; server-side `report_event` advances every matching active quest — there is **no public endpoint to advance progress** (server-authoritative) - **Rewards**: currencies (Economy) and items (Inventory), paid **exactly once** per period via idempotent grants; `auto_claim` quests pay on completion, others via `POST /me/quests/:key/claim` - **My quests**: `GET /me/quests` returns active quests, per-period progress, and a claimable flag; hidden quests appear once completed - **Catalog**: `GET /quests` and per-user completions `GET /quests/user/:user_id` (gated by `LIST_QUESTS_ENABLED`) - **Admin management**: definitions CRUD plus per-user grant/reset/force-claim under `/api/v1/admin/quests`  ## **12. Tournaments** Single-elimination bracket tournaments, server-structured and game-judged:  - **Registration window → seeded draw → timed rounds → champions**; recurring tournaments (cron) create one occurrence per cycle sharing a slug; a nil starts_at keeps registration open until an admin draws manually - **Join/leave** as an entry leader (`POST`/`DELETE /tournaments/:id/join`); team composition is game policy - **Browse**: list/filter tournaments, standings, full bracket view, and the caller's current match (`GET /tournaments/:id/my-match`) - **Match verdicts are server-side** (game hooks) — no public resolve endpoint; clients get `tournament_match_ready` / `tournament_match_resolved` / `tournament_updated` / `tournament_finished` on the user channel - **Admin management** over HTTP: create/update/delete, cancel, draw now, finish, and force match verdicts under `/api/v1/admin/tournaments`  ## **13. Matchmaking** Ticket-based queueing that turns waiting players into hidden, locked lobbies:  - **Join over HTTP** (`POST /matchmaking/tickets` with a `match_params` string map); only tickets with identical params match together — encode mode/map/skill band as parameter values - **A match forms** when a group reaches `max_players`, or has at least `min_players` and the oldest ticket outwaited the timeout; the server creates a hidden lobby, seats everyone and locks it - **The result is a push, not a poll**: matched players receive `match_found` (`lobby_id`, `match_params`) on their user channel; disconnecting cancels your tickets - **Inspect**: `GET /matchmaking/tickets/me` for your ticket, `GET /matchmaking/stats` for queue depths - **Admin management** over HTTP: list/filter tickets, force-cancel, and stats under `/api/v1/admin/matchmaking`  ## **14. Ready checks** One primitive for \"everyone must answer before this proceeds\", with one client-facing surface:  - **A player holds at most one check per lane** — the match lane (lobby ready-up or matchmaking accept) and the party lane (the party's standing board) — so answering needs no id: `GET /me/ready_check` returns `{\"lobby\": …, \"party\": …}` (each null when none) and `POST /me/ready_check` with `{\"ready\": true|false, \"scope\": \"lobby\"|\"party\"}` answers one (scope defaults to `lobby`) - **Two kinds.** `ready` (lobby/party board) is a toggle — a \"no\" just leaves the check open, and it lists every participant. `accept` (match confirmation) is final — one decline fails it for everyone — and returns counts plus your own state, so a pending match does not reveal who you were paired with - **Hosts open one** with `POST /lobbies/ready_check` (host-managed lobbies only; hostless matchmaking lobbies belong to the server), **party leaders** with `POST /parties/ready_check`; either call is a **reset** — it quietly replaces an already-open board with a fresh one over the current members, so the same endpoint serves \"ready check!\", \"force ready\" (with `timeout_ms`) and \"start over\". Call it off with `DELETE /lobbies/ready_check` / `DELETE /parties/ready_check`. The opener is pre-marked ready — clicking the button is their answer - **Failure does nothing on its own**: a declined or timed-out check kicks nobody, starts nothing, and moves no lobby state. It reports who did not answer, and the game (or the host, with the kick they already have) decides - **Live**: `ready_check_started` / `ready_check_updated` / `ready_check_passed` / `ready_check_failed` on the lobby channel, the party channel for a party board, or the user channel for an accept check - **Admin management** over HTTP: list/filter checks, force-cancel, and 24h outcome stats under `/api/v1/admin/ready_checks`  ## **15. Real-time: WebSocket Channels** The server provides real-time communication via Phoenix WebSocket channels. Connect to the WebSocket endpoint and join topic-based channels for live updates.  ### **15.1 Connection** Connect to `wss://your-server.com/socket` with your JWT token as a parameter: ``` const socket = new Socket(\"wss://your-server.com/socket\", { params: { token: \"<access_token>\" } }) socket.connect() ```  ### **15.2 Available Channels** - **User channel** (`user:<user_id>`): notifications, friend events, quest progress/completions/claims, party/group invites, tournament events, KV subscriptions - **Lobby channel** (`lobby:<lobby_id>`): lobby member joins/leaves, lobby updates, lobby chat - **Lobbies channel** (`lobbies`): global lobby list changes (created, updated, deleted) - **Group channel** (`group:<group_id>`): group member changes, group updates, group chat - **Groups channel** (`groups`): global group list changes - **Party channel** (`party:<party_id>`): party member changes, party updates, party chat  ### **15.3 JS SDK Helper** The `GameRealtime` class (included in this SDK) wraps Phoenix.Socket with convenient channel helpers: ```javascript import { GameRealtime } from '@ughuuu/game_server' const realtime = new GameRealtime('https://your-server.com', accessToken) const userChannel = realtime.joinUserChannel(userId) userChannel.on('notification', payload => console.log(payload)) ``` Requires the `phoenix` npm package as a peer dependency: `npm install phoenix`  ## **16. Real-time: WebRTC DataChannels** For low-latency game data, the server supports WebRTC DataChannels alongside WebSocket. The server acts as a WebRTC peer (not P2P between clients).  ### **16.1 How It Works** 1. Client connects via WebSocket and joins the **User channel** 2. Client sends an SDP offer over the channel (`webrtc:offer` event) 3. Server responds with an SDP answer (`webrtc:answer` event) 4. ICE candidates are exchanged (`webrtc:ice` events) 5. Once connected, named DataChannels carry game data at low latency  ### **16.2 Default DataChannels** - **`events`** (reliable, ordered): important game events (player actions, state changes) - **`state`** (unreliable, unordered): high-frequency position/state sync  ### **16.3 JS SDK Helper** The `GameWebRTC` class (included in this SDK, browser-only) handles signaling automatically: ```javascript import { GameRealtime, GameWebRTC } from '@ughuuu/game_server' const realtime = new GameRealtime('https://your-server.com', token) const userChannel = realtime.joinUserChannel(userId) const webrtc = new GameWebRTC(userChannel, {   onData: (label, data) => console.log(label, data) }) await webrtc.connect() webrtc.send('events', JSON.stringify({ type: 'move', x: 10, y: 20 })) ``` 
  *
- * The version of the OpenAPI document: 1.0.1059
+ * The version of the OpenAPI document: 1.0.1070
  * 
  *
  * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).

package/dist/api/AdminEconomyApi.js

@@ -16,9 +16,9 @@ function _createClass(e, r, t) { return r && _defineProperties(e.prototype, r),
 function _toPropertyKey(t) { var i = _toPrimitive(t, "string"); return "symbol" == _typeof(i) ? i : i + ""; }
 function _toPrimitive(t, r) { if ("object" != _typeof(t) || !t) return t; var e = t[Symbol.toPrimitive]; if (void 0 !== e) { var i = e.call(t, r || "default"); if ("object" != _typeof(i)) return i; throw new TypeError("@@toPrimitive must return a primitive value."); } return ("string" === r ? String : Number)(t); } /**
  * Game Server API
- * API for the Gamend Game Server. Provides HTTP REST API, real-time WebSocket channels, and WebRTC DataChannels for low-latency game data. Features authentication, users, lobbies, groups, parties, friends, chat, notifications, achievements, leaderboards, tournaments, matchmaking, payments, server scripting, and admin portal.  ## **1. Authentication**  This API uses JWT (JSON Web Tokens) with access and refresh tokens:  ### **1.1 Getting Tokens** - **Email/Password**: POST to `/api/v1/login` with email and password - **Device (SDK)**: POST to `/api/v1/login` with a `device_id` string (creates/returns a device user) - **Discord OAuth**: Use `/api/v1/auth/discord` flow - **Google OAuth**: Use `/api/v1/auth/google` flow - **Facebook OAuth**: Use `/api/v1/auth/facebook` flow - **Apple Sign In**: Use `/auth/apple` browser flow or apple sdk flow - **Steam (OpenID)**: Use `/api/v1/auth/steam` flow  Both methods return: - `access_token` - Short-lived (15 min), use for API requests - `refresh_token` - Long-lived (30 days), use to get new access tokens  ### **1.2 Using Tokens** Include the access token in the Authorization header: ``` Authorization: Bearer <access_token> ```  ### **1.3 Refreshing Tokens** When your access token expires, use POST `/api/v1/refresh` with your refresh token to get a new access token.  ## **2. Users** Users endpoints cover the user lifecycle and profile features. Key highlights:  - **Registration and login** (email/password, device token for SDKs, and OAuth providers) - **Profile metadata** (JSON blob per user) and editable profile fields - **Account lifecycle**: password reset, email confirmation, and account deletion - **Sessions & tokens**: both browser sessions and JWT-based API tokens are supported  ## **3. Friends** The Friends domain offers lightweight social features:  - **Friend requests** (send / accept / reject / block flows) - **Friend listing & pagination**, with basic privacy controls - **Domain helpers** to manage and query friend relationships from API or UI contexts  ## **4. Lobbies** Lobbies provide matchmaking / room management primitives. Highlights:  - **Create / list / update / delete** lobbies with rich metadata (mode, region, tags) - **Host-managed or hostless** modes (hostless allowed internally, not creatable via public API) - **Membership management**: join, leave, kick users, and automatic host transfer - **Controls & protection**: max users, hidden/locked states, and optional password protection - **Hidden lobbies** are excluded from public listings; public listing endpoints are paginated  ## **5. Notifications** Persistent user-to-user notifications that survive across sessions:  - **Send notifications** to accepted friends with a title, optional content, and optional metadata - **List own notifications** with pagination (ordered oldest-first) - **Delete notifications** by ID (single or batch) - **Real-time delivery** via the user WebSocket channel (`\"notification\"` events) - **Offline delivery**: undeleted notifications are replayed on WebSocket reconnect  ## **6. Groups** Groups provide persistent community management for players:  - **Three group types**: `public` (anyone joins directly), `private` (users request to join, admins approve), `hidden` (invite-only, never listed) - **Membership roles**: `admin` and `member`, with promote/demote capabilities - **Join requests**: for private groups, users submit requests that admins approve or reject - **Invitations**: admins can invite users directly (blocked users are rejected) - **CRUD operations**: create, update, delete groups with metadata support - **Group chat**: integrated via the Chat API with `chat_type: \"group\"`  ## **7. Parties** Ephemeral groups of users for short-lived sessions (e.g., matchmaking squads):  - **Invite-only joining**: the party leader sends invites by user ID to friends or shared-group members - **Invite flow**: `POST /parties/invite` → recipient accepts via `POST /parties/invite/accept` or declines via `POST /parties/invite/decline`; leader can cancel via `POST /parties/invite/cancel` - **Invite visibility**: leader can list sent invites (`GET /parties/invitations/sent`); recipient can list received invites (`GET /parties/invitations`) - **Connection requirement**: invites can only be sent to users who are friends or share at least one group with the leader - **One party at a time**: a user can only be in one party; accepting an invite while already in a party is rejected - **Leader management**: the creator is the leader; leadership can be transferred - **Lobby integration**: parties can create or join lobbies as a group - **Party chat**: integrated via the Chat API with `chat_type: \"party\"` - **Real-time events** via the party WebSocket channel  ## **8. Chat** Real-time messaging across multiple conversation types:  - **Chat types**: `lobby` (within a lobby), `group` (within a group), `party` (within a party), `friend` (DMs between friends) - **Send messages** with content, optional metadata, and automatic access validation - **List messages** with pagination (newest first) - **Read tracking**: mark messages as read and get unread counts per conversation - **Real-time delivery** via PubSub and WebSocket channels - **Moderation hooks**: `before_chat_message` pipeline hook for filtering/blocking  ## **9. Leaderboards** Server-managed ranked scoreboards:  - **Multiple leaderboards**: create named leaderboards with configurable sort order - **Score submission**: submit scores with optional metadata - **Rankings**: retrieve paginated rankings with user details - **Reset support**: leaderboards can be reset periodically  ## **10. Key-Value Storage** Per-user persistent key-value storage for game state, preferences, and settings:  - **Get/set/delete** key-value pairs scoped to the authenticated user - **List keys** with optional prefix filtering - **Metadata support**: values can include arbitrary JSON metadata  ## **11. Achievements** Track player accomplishments with progress-based or instant-unlock achievements:  - **Achievement definitions**: admin-created with slug, title, description, icon, sort order, and optional progress target - **Progress tracking**: increment progress toward a target; auto-unlocks when progress reaches the target - **Instant unlock**: directly unlock achievements without progress tracking - **Hidden achievements**: details obscured (\"???\") until unlocked by the user - **Public listings**: paginated, optionally filtered; authenticated users see their own progress - **Admin management**: create, update, delete, grant, revoke, unlock, and increment achievements  ## **12. Tournaments** Single-elimination bracket tournaments, server-structured and game-judged:  - **Registration window → seeded draw → timed rounds → champions**; recurring tournaments (cron) create one occurrence per cycle sharing a slug; a nil starts_at keeps registration open until an admin draws manually - **Join/leave** as an entry leader (`POST`/`DELETE /tournaments/:id/join`); team composition is game policy - **Browse**: list/filter tournaments, standings, full bracket view, and the caller's current match (`GET /tournaments/:id/my-match`) - **Match verdicts are server-side** (game hooks) — no public resolve endpoint; clients get `tournament_match_ready` / `tournament_match_resolved` / `tournament_updated` / `tournament_finished` on the user channel - **Admin management** over HTTP: create/update/delete, cancel, draw now, finish, and force match verdicts under `/api/v1/admin/tournaments`  ## **13. Matchmaking** Ticket-based queueing that turns waiting players into hidden, locked lobbies:  - **Join over HTTP** (`POST /matchmaking/tickets` with a `match_params` string map); only tickets with identical params match together — encode mode/map/skill band as parameter values - **A match forms** when a group reaches `max_players`, or has at least `min_players` and the oldest ticket outwaited the timeout; the server creates a hidden lobby, seats everyone and locks it - **The result is a push, not a poll**: matched players receive `match_found` (`lobby_id`, `match_params`) on their user channel; disconnecting cancels your tickets - **Inspect**: `GET /matchmaking/tickets/me` for your ticket, `GET /matchmaking/stats` for queue depths - **Admin management** over HTTP: list/filter tickets, force-cancel, and stats under `/api/v1/admin/matchmaking`  ## **14. Real-time: WebSocket Channels** The server provides real-time communication via Phoenix WebSocket channels. Connect to the WebSocket endpoint and join topic-based channels for live updates.  ### **14.1 Connection** Connect to `wss://your-server.com/socket` with your JWT token as a parameter: ``` const socket = new Socket(\"wss://your-server.com/socket\", { params: { token: \"<access_token>\" } }) socket.connect() ```  ### **14.2 Available Channels** - **User channel** (`user:<user_id>`): notifications, friend events, achievement unlocks, party/group invites, tournament events, KV subscriptions - **Lobby channel** (`lobby:<lobby_id>`): lobby member joins/leaves, lobby updates, lobby chat - **Lobbies channel** (`lobbies`): global lobby list changes (created, updated, deleted) - **Group channel** (`group:<group_id>`): group member changes, group updates, group chat - **Groups channel** (`groups`): global group list changes - **Party channel** (`party:<party_id>`): party member changes, party updates, party chat  ### **14.3 JS SDK Helper** The `GameRealtime` class (included in this SDK) wraps Phoenix.Socket with convenient channel helpers: ```javascript import { GameRealtime } from '@ughuuu/game_server' const realtime = new GameRealtime('https://your-server.com', accessToken) const userChannel = realtime.joinUserChannel(userId) userChannel.on('notification', payload => console.log(payload)) ``` Requires the `phoenix` npm package as a peer dependency: `npm install phoenix`  ## **15. Real-time: WebRTC DataChannels** For low-latency game data, the server supports WebRTC DataChannels alongside WebSocket. The server acts as a WebRTC peer (not P2P between clients).  ### **15.1 How It Works** 1. Client connects via WebSocket and joins the **User channel** 2. Client sends an SDP offer over the channel (`webrtc:offer` event) 3. Server responds with an SDP answer (`webrtc:answer` event) 4. ICE candidates are exchanged (`webrtc:ice` events) 5. Once connected, named DataChannels carry game data at low latency  ### **15.2 Default DataChannels** - **`events`** (reliable, ordered): important game events (player actions, state changes) - **`state`** (unreliable, unordered): high-frequency position/state sync  ### **15.3 JS SDK Helper** The `GameWebRTC` class (included in this SDK, browser-only) handles signaling automatically: ```javascript import { GameRealtime, GameWebRTC } from '@ughuuu/game_server' const realtime = new GameRealtime('https://your-server.com', token) const userChannel = realtime.joinUserChannel(userId) const webrtc = new GameWebRTC(userChannel, {   onData: (label, data) => console.log(label, data) }) await webrtc.connect() webrtc.send('events', JSON.stringify({ type: 'move', x: 10, y: 20 })) ``` 
+ * API for the Gamend Game Server. Provides HTTP REST API, real-time WebSocket channels, and WebRTC DataChannels for low-latency game data. Features authentication, users, lobbies, groups, parties, friends, chat, notifications, quests, leaderboards, tournaments, matchmaking, payments, server scripting, and admin portal.  ## **1. Authentication**  This API uses JWT (JSON Web Tokens) with access and refresh tokens:  ### **1.1 Getting Tokens** - **Email/Password**: POST to `/api/v1/login` with email and password - **Device (SDK)**: POST to `/api/v1/login` with a `device_id` string (creates/returns a device user) - **Discord OAuth**: Use `/api/v1/auth/discord` flow - **Google OAuth**: Use `/api/v1/auth/google` flow - **Facebook OAuth**: Use `/api/v1/auth/facebook` flow - **Apple Sign In**: Use `/auth/apple` browser flow or apple sdk flow - **Steam (OpenID)**: Use `/api/v1/auth/steam` flow  Both methods return: - `access_token` - Short-lived (15 min), use for API requests - `refresh_token` - Long-lived (30 days), use to get new access tokens  ### **1.2 Using Tokens** Include the access token in the Authorization header: ``` Authorization: Bearer <access_token> ```  ### **1.3 Refreshing Tokens** When your access token expires, use POST `/api/v1/refresh` with your refresh token to get a new access token.  ## **2. Users** Users endpoints cover the user lifecycle and profile features. Key highlights:  - **Registration and login** (email/password, device token for SDKs, and OAuth providers) - **Profile metadata** (JSON blob per user) and editable profile fields - **Account lifecycle**: password reset, email confirmation, and account deletion - **Sessions & tokens**: both browser sessions and JWT-based API tokens are supported  ## **3. Friends** The Friends domain offers lightweight social features:  - **Friend requests** (send / accept / reject / block flows) - **Friend listing & pagination**, with basic privacy controls - **Domain helpers** to manage and query friend relationships from API or UI contexts  ## **4. Lobbies** Lobbies provide matchmaking / room management primitives. Highlights:  - **Create / list / update / delete** lobbies with rich metadata (mode, region, tags) - **Host-managed or hostless** modes (hostless allowed internally, not creatable via public API) - **Membership management**: join, leave, kick users, and automatic host transfer - **Controls & protection**: max users, hidden/locked states, and optional password protection - **Hidden lobbies** are excluded from public listings; public listing endpoints are paginated  ## **5. Notifications** Persistent user-to-user notifications that survive across sessions:  - **Send notifications** to accepted friends with a title, optional content, and optional metadata - **List own notifications** with pagination (ordered oldest-first) - **Delete notifications** by ID (single or batch) - **Real-time delivery** via the user WebSocket channel (`\"notification\"` events) - **Offline delivery**: undeleted notifications are replayed on WebSocket reconnect - **Push delivery**: notifications also fan out to the recipient's registered mobile devices (see Push notifications)  ## **5b. Push notifications** Mobile/web push delivery to registered devices (FCM for Android/Web, APNs-direct for iOS):  - **Register device tokens** via `POST /me/push-tokens` (`token`, `platform`, optional `provider`/`device_id`); re-registering a `device_id` rotates its token in place - **List/remove own devices** via `GET /me/push-tokens` and `DELETE /me/push-tokens/:id` - **Server-authoritative sending** — no public send endpoint; pushes originate from server hooks (`GameServer.Push.send_to_user/2`) or the admin API - **Per-token routing**: each token's `provider` (\"fcm\" | \"apns\") selects the delivery backend; unconfigured backends log instead of sending (dev-friendly) - **Reliability**: delivery rides the durable job queue with retries; dead tokens reported by the provider are disabled automatically  ## **6. Groups** Groups provide persistent community management for players:  - **Three group types**: `public` (anyone joins directly), `private` (users request to join, admins approve), `hidden` (invite-only, never listed) - **Membership roles**: `admin` and `member`, with promote/demote capabilities - **Join requests**: for private groups, users submit requests that admins approve or reject - **Invitations**: admins can invite users directly (blocked users are rejected) - **CRUD operations**: create, update, delete groups with metadata support - **Group chat**: integrated via the Chat API with `chat_type: \"group\"`  ## **7. Parties** Ephemeral groups of users for short-lived sessions (e.g., matchmaking squads):  - **Invite-only joining**: the party leader sends invites by user ID to friends or shared-group members - **Invite flow**: `POST /parties/invite` → recipient accepts via `POST /parties/invite/accept` or declines via `POST /parties/invite/decline`; leader can cancel via `POST /parties/invite/cancel` - **Invite visibility**: leader can list sent invites (`GET /parties/invitations/sent`); recipient can list received invites (`GET /parties/invitations`) - **Connection requirement**: invites can only be sent to users who are friends or share at least one group with the leader - **One party at a time**: a user can only be in one party; accepting an invite while already in a party is rejected - **Leader management**: the creator is the leader; leadership can be transferred - **Lobby integration**: parties can create or join lobbies as a group - **Party chat**: integrated via the Chat API with `chat_type: \"party\"` - **Real-time events** via the party WebSocket channel  ## **8. Chat** Real-time messaging across multiple conversation types:  - **Chat types**: `lobby` (within a lobby), `group` (within a group), `party` (within a party), `friend` (DMs between friends) - **Send messages** with content, optional metadata, and automatic access validation - **List messages** with pagination (newest first) - **Read tracking**: mark messages as read and get unread counts per conversation - **Real-time delivery** via PubSub and WebSocket channels - **Moderation hooks**: `before_chat_message` pipeline hook for filtering/blocking  ## **9. Leaderboards** Server-managed ranked scoreboards:  - **Multiple leaderboards**: create named leaderboards with configurable sort order - **Score submission**: submit scores with optional metadata - **Rankings**: retrieve paginated rankings with user details - **Reset support**: leaderboards can be reset periodically  ## **10. Key-Value Storage** Per-user persistent key-value storage for game state, preferences, and settings:  - **Get/set/delete** key-value pairs scoped to the authenticated user - **List keys** with optional prefix filtering - **Metadata support**: values can include arbitrary JSON metadata  ## **11. Quests / Progression** One event-driven progression engine covering achievements, daily/weekly quests, time-boxed event quests, and chains:  - **Kinds**: `achievement` (permanent one-shot — the replacement for the old achievements system), `daily`/`weekly` (reset per UTC period), `event` (starts_at/ends_at window), `chain` (requires a prerequisite quest) - **Objectives**: each quest lists objectives `{event, target, params}`; server-side `report_event` advances every matching active quest — there is **no public endpoint to advance progress** (server-authoritative) - **Rewards**: currencies (Economy) and items (Inventory), paid **exactly once** per period via idempotent grants; `auto_claim` quests pay on completion, others via `POST /me/quests/:key/claim` - **My quests**: `GET /me/quests` returns active quests, per-period progress, and a claimable flag; hidden quests appear once completed - **Catalog**: `GET /quests` and per-user completions `GET /quests/user/:user_id` (gated by `LIST_QUESTS_ENABLED`) - **Admin management**: definitions CRUD plus per-user grant/reset/force-claim under `/api/v1/admin/quests`  ## **12. Tournaments** Single-elimination bracket tournaments, server-structured and game-judged:  - **Registration window → seeded draw → timed rounds → champions**; recurring tournaments (cron) create one occurrence per cycle sharing a slug; a nil starts_at keeps registration open until an admin draws manually - **Join/leave** as an entry leader (`POST`/`DELETE /tournaments/:id/join`); team composition is game policy - **Browse**: list/filter tournaments, standings, full bracket view, and the caller's current match (`GET /tournaments/:id/my-match`) - **Match verdicts are server-side** (game hooks) — no public resolve endpoint; clients get `tournament_match_ready` / `tournament_match_resolved` / `tournament_updated` / `tournament_finished` on the user channel - **Admin management** over HTTP: create/update/delete, cancel, draw now, finish, and force match verdicts under `/api/v1/admin/tournaments`  ## **13. Matchmaking** Ticket-based queueing that turns waiting players into hidden, locked lobbies:  - **Join over HTTP** (`POST /matchmaking/tickets` with a `match_params` string map); only tickets with identical params match together — encode mode/map/skill band as parameter values - **A match forms** when a group reaches `max_players`, or has at least `min_players` and the oldest ticket outwaited the timeout; the server creates a hidden lobby, seats everyone and locks it - **The result is a push, not a poll**: matched players receive `match_found` (`lobby_id`, `match_params`) on their user channel; disconnecting cancels your tickets - **Inspect**: `GET /matchmaking/tickets/me` for your ticket, `GET /matchmaking/stats` for queue depths - **Admin management** over HTTP: list/filter tickets, force-cancel, and stats under `/api/v1/admin/matchmaking`  ## **14. Ready checks** One primitive for \"everyone must answer before this proceeds\", with one client-facing surface:  - **A player holds at most one check per lane** — the match lane (lobby ready-up or matchmaking accept) and the party lane (the party's standing board) — so answering needs no id: `GET /me/ready_check` returns `{\"lobby\": …, \"party\": …}` (each null when none) and `POST /me/ready_check` with `{\"ready\": true|false, \"scope\": \"lobby\"|\"party\"}` answers one (scope defaults to `lobby`) - **Two kinds.** `ready` (lobby/party board) is a toggle — a \"no\" just leaves the check open, and it lists every participant. `accept` (match confirmation) is final — one decline fails it for everyone — and returns counts plus your own state, so a pending match does not reveal who you were paired with - **Hosts open one** with `POST /lobbies/ready_check` (host-managed lobbies only; hostless matchmaking lobbies belong to the server), **party leaders** with `POST /parties/ready_check`; either call is a **reset** — it quietly replaces an already-open board with a fresh one over the current members, so the same endpoint serves \"ready check!\", \"force ready\" (with `timeout_ms`) and \"start over\". Call it off with `DELETE /lobbies/ready_check` / `DELETE /parties/ready_check`. The opener is pre-marked ready — clicking the button is their answer - **Failure does nothing on its own**: a declined or timed-out check kicks nobody, starts nothing, and moves no lobby state. It reports who did not answer, and the game (or the host, with the kick they already have) decides - **Live**: `ready_check_started` / `ready_check_updated` / `ready_check_passed` / `ready_check_failed` on the lobby channel, the party channel for a party board, or the user channel for an accept check - **Admin management** over HTTP: list/filter checks, force-cancel, and 24h outcome stats under `/api/v1/admin/ready_checks`  ## **15. Real-time: WebSocket Channels** The server provides real-time communication via Phoenix WebSocket channels. Connect to the WebSocket endpoint and join topic-based channels for live updates.  ### **15.1 Connection** Connect to `wss://your-server.com/socket` with your JWT token as a parameter: ``` const socket = new Socket(\"wss://your-server.com/socket\", { params: { token: \"<access_token>\" } }) socket.connect() ```  ### **15.2 Available Channels** - **User channel** (`user:<user_id>`): notifications, friend events, quest progress/completions/claims, party/group invites, tournament events, KV subscriptions - **Lobby channel** (`lobby:<lobby_id>`): lobby member joins/leaves, lobby updates, lobby chat - **Lobbies channel** (`lobbies`): global lobby list changes (created, updated, deleted) - **Group channel** (`group:<group_id>`): group member changes, group updates, group chat - **Groups channel** (`groups`): global group list changes - **Party channel** (`party:<party_id>`): party member changes, party updates, party chat  ### **15.3 JS SDK Helper** The `GameRealtime` class (included in this SDK) wraps Phoenix.Socket with convenient channel helpers: ```javascript import { GameRealtime } from '@ughuuu/game_server' const realtime = new GameRealtime('https://your-server.com', accessToken) const userChannel = realtime.joinUserChannel(userId) userChannel.on('notification', payload => console.log(payload)) ``` Requires the `phoenix` npm package as a peer dependency: `npm install phoenix`  ## **16. Real-time: WebRTC DataChannels** For low-latency game data, the server supports WebRTC DataChannels alongside WebSocket. The server acts as a WebRTC peer (not P2P between clients).  ### **16.1 How It Works** 1. Client connects via WebSocket and joins the **User channel** 2. Client sends an SDP offer over the channel (`webrtc:offer` event) 3. Server responds with an SDP answer (`webrtc:answer` event) 4. ICE candidates are exchanged (`webrtc:ice` events) 5. Once connected, named DataChannels carry game data at low latency  ### **16.2 Default DataChannels** - **`events`** (reliable, ordered): important game events (player actions, state changes) - **`state`** (unreliable, unordered): high-frequency position/state sync  ### **16.3 JS SDK Helper** The `GameWebRTC` class (included in this SDK, browser-only) handles signaling automatically: ```javascript import { GameRealtime, GameWebRTC } from '@ughuuu/game_server' const realtime = new GameRealtime('https://your-server.com', token) const userChannel = realtime.joinUserChannel(userId) const webrtc = new GameWebRTC(userChannel, {   onData: (label, data) => console.log(label, data) }) await webrtc.connect() webrtc.send('events', JSON.stringify({ type: 'move', x: 10, y: 20 })) ``` 
  *
- * The version of the OpenAPI document: 1.0.1059
+ * The version of the OpenAPI document: 1.0.1070
  * 
  *
  * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).