# **WECHESS** **FRONTEND GUIDE FOR AI CODING AGENTS - PART 9 - LobbyChat Service** This document is a part of a REST API guide for the wechess project. It is designed for AI agents that will generate frontend code to consume the project’s backend. This document provides extensive instruction for the usage of lobbyChat ## Service Access LobbyChat service management is handled through service specific base urls. LobbyChat service may be deployed to the preview server, staging server, or production server. Therefore,it has 3 access URLs. The frontend application must support all deployment environments during development, and the user should be able to select the target API server on the login page (already handled in first part.). For the lobbyChat service, the base URLs are: * **Preview:** `https://wechess.prw.mindbricks.com/lobbychat-api` * **Staging:** `https://wechess-stage.mindbricks.co/lobbychat-api` * **Production:** `https://wechess.mindbricks.co/lobbychat-api` ## Scope **LobbyChat Service Description** Public lobby chat microservice. Manages create, list, reporting, moderation, and 24-hour message expiry for guest/registered users. LobbyChat service provides apis and business logic for following data objects in wechess application. Each data object may be either a central domain of the application data structure or a related helper data object for a central concept. Note that data object concept is equal to table concept in the database, in the service database each data object is represented as a db table scheme and the object instances as table rows. **`lobbyMessage` Data Object**: A single lobby/public chat message between any logged-in user (guest, registered, admin). Ephemeral (24h retention), with reporting and moderation support. Muting is tracked by senderId+mutedUntil for punishment management. **`lobbyRoom` Data Object**: Daily lobby chat room. One record per day (roomId format: lobby-YYYY-MM-DD). Older rooms kept as history. **`lobbyChatHubMessage` Data Object**: Auto-generated message DataObject for the lobbyChatHub RealtimeHub. Stores all messages with typed content payloads. **`lobbyChatHubModeration` Data Object**: Auto-generated moderation DataObject for the lobbyChatHub RealtimeHub. Stores block and silence actions for room-level user moderation. ## LobbyChat Service Frontend Description By The Backend Architect # Lobby Chat Service (lobbyChat) - Provides the public chat visible to all players in the lobby. - Messages appear in reverse chronological order, newest first. - Messages older than 24 hours are not shown. - Muted guests/players cannot send messages (see error on send UI). - When a message is reported, UI updates indicator/badge for message and disables input for further reports until admin review/resolution. - Administrators may remove/hide messages and mute senders via moderation UI. - When a message is removed, frontend hides or overlays UI as "removed by moderation". - For guests, use session auth to avoid accidental message loss or spoofing. - Scrolling/loading fetches messages from past 24 hours only. - No message editing; messages are either visible (unremoved) or hidden/flagged. ## API Structure ### Object Structure of a Successful Response When the service processes requests successfully, it wraps the requested resource(s) within a JSON envelope. This envelope includes the data and essential metadata such as configuration details and pagination information, providing context to the client. **HTTP Status Codes:** * **200 OK**: Returned for successful GET, LIST, UPDATE, or DELETE operations, indicating that the request was processed successfully. * **201 Created**: Returned for CREATE operations, indicating that the resource was created successfully. **Success Response Format:** For successful operations, the response includes a `"status": "OK"` property, signaling that the request executed successfully. The structure of a successful response is outlined below: ```json { "status":"OK", "statusCode": 200, "elapsedMs":126, "ssoTime":120, "source": "db", "cacheKey": "hexCode", "userId": "ID", "sessionId": "ID", "requestId": "ID", "dataName":"products", "method":"GET", "action":"list", "appVersion":"Version", "rowCount":3, "products":[{},{},{}], "paging": { "pageNumber":1, "pageRowCount":25, "totalRowCount":3, "pageCount":1 }, "filters": [], "uiPermissions": [] } ``` * **`products`**: In this example, this key contains the actual response content, which may be a single object or an array of objects depending on the operation. ### Additional Data Each API may include additional data besides the main data object, depending on the business logic of the API. These will be provided in each API’s response signature. ### Error Response If a request encounters an issue—whether due to a logical fault or a technical problem—the service responds with a standardized JSON error structure. The HTTP status code indicates the nature of the error, using commonly recognized codes for clarity: * **400 Bad Request**: The request was improperly formatted or contained invalid parameters. * **401 Unauthorized**: The request lacked a valid authentication token; login is required. * **403 Forbidden**: The current token does not grant access to the requested resource. * **404 Not Found**: The requested resource was not found on the server. * **500 Internal Server Error**: The server encountered an unexpected condition. Each error response is structured to provide meaningful insight into the problem, assisting in efficient diagnosis and resolution. ```js { "result": "ERR", "status": 400, "message": "errMsg_organizationIdisNotAValidID", "errCode": 400, "date": "2024-03-19T12:13:54.124Z", "detail": "String" } ``` ## LobbyMessage Data Object A single lobby/public chat message between any logged-in user (guest, registered, admin). Ephemeral (24h retention), with reporting and moderation support. Muting is tracked by senderId+mutedUntil for punishment management. ### LobbyMessage Data Object Frontend Description By The Backend Architect - Each message includes sender name and profile/avatar (provided by frontend via user context). - Messages are visible to all online users for 24 hours. Older messages are not shown in the lobby chat UI. - Guests and registered users appear in the same stream, with visual distinction only in the frontend if required. - Messages flagged as removed are hidden or replaced visually as 'removed by moderation.' - Users who are muted (mutedUntil > now) are prevented from sending new messages and will see a mute notice on input. - Reporting is instant; if a message is reported, UI disables repeat reports for that user on the message. - No editing; removal (admin) and reporting (all users) are permanent per message. ### LobbyMessage Data Object Properties LobbyMessage data object has got following properties that are represented as table fields in the database scheme. These properties don't stand just for data storage, but each may have different settings to manage the business logic. | Property | Type | IsArray | Required | Secret | Description | |----------|------|---------|----------|--------|-------------| | `senderId` | ID | false | Yes | No | User ID (guest or registered) who sent the message. References auth:user.id. | | `senderDisplayName` | String | false | Yes | No | Display name (from user fullname at send time; allows historical display even if name changes). | | `content` | String | false | Yes | No | Chat message body (limited at UI, backend-enforces not empty; max 500 chars). | | `sentAt` | Date | false | Yes | No | UTC timestamp when message was sent. Used to enforce 24h retention and sorting. | | `reportStatus` | Enum | false | Yes | No | Moderation/report workflow state: none (default), reported (user), underReview (admin). | | `mutedUntil` | Date | false | No | No | If set, the message sender is muted in the lobby until this timestamp. Only admins may set. Used with senderId for lookup on enforcement. | | `removed` | Boolean | false | Yes | No | If true, message is hidden/removed by admin moderation (soft-remove). | | `roomId` | String | false | Yes | No | Daily room identifier (lobby-YYYY-MM-DD). Scopes message to that day. | * Required properties are mandatory for creating objects and must be provided in the request body if no default value, formula or session bind is set. ### Enum Properties Enum properties are defined with a set of allowed values, ensuring that only valid options can be assigned to them. The enum options value will be stored as strings in the database, but when a data object is created an additional property with the same name plus an idx suffix will be created, which will hold the index of the selected enum option. You can use the {fieldName_idx} property to sort by the enum value or when your enum options represent a hiyerarchy of values. In the frontend input components, enum type properties should only accept values from an option component that lists the enum options. - **reportStatus**: [none, reported, underReview] ### Relation Properties `senderId` Mindbricks supports relations between data objects, allowing you to define how objects are linked together. The relations may reference to a data object either in this service or in another service. Id the reference is remote, backend handles the relations through service communication or elastic search. These relations should be respected in the frontend so that instaead of showing the related objects id, the frontend should list human readable values from other data objects. If the relation points to another service, frontend should use the referenced service api in case it needs related data. The relation logic is montly handled in backend so the api responses feeds the frontend about the relational data. In mmost cases the api response will provide the relational data as well as the main one. In frontend, please ensure that, 1- instaead of these relational ids you show the main human readable field of the related target data (like name), 2- if this data object needs a user input of these relational ids, you should provide a combobox with the list of possible records or (a searchbox) to select with the realted target data object main human readable field. - **senderId**: ID Relation to `user`.id The target object is a parent object, meaning that the relation is a one-to-many relationship from target to this object. Required: Yes ### Filter Properties `senderId` `reportStatus` `removed` Filter properties are used to define parameters that can be used in query filters, allowing for dynamic data retrieval based on user input or predefined criteria. These properties are automatically mapped as API parameters in the listing API's. - **senderId**: ID has a filter named `senderId` - **reportStatus**: Enum has a filter named `reportStatus` - **removed**: Boolean has a filter named `removed` ## LobbyRoom Data Object Daily lobby chat room. One record per day (roomId format: lobby-YYYY-MM-DD). Older rooms kept as history. ### LobbyRoom Data Object Properties LobbyRoom data object has got following properties that are represented as table fields in the database scheme. These properties don't stand just for data storage, but each may have different settings to manage the business logic. | Property | Type | IsArray | Required | Secret | Description | |----------|------|---------|----------|--------|-------------| | `roomId` | String | false | Yes | No | Room identifier, e.g. lobby-2026-03-10 | * Required properties are mandatory for creating objects and must be provided in the request body if no default value, formula or session bind is set. ## LobbyChatHubMessage Data Object Auto-generated message DataObject for the lobbyChatHub RealtimeHub. Stores all messages with typed content payloads. ### LobbyChatHubMessage Data Object Properties LobbyChatHubMessage data object has got following properties that are represented as table fields in the database scheme. These properties don't stand just for data storage, but each may have different settings to manage the business logic. | Property | Type | IsArray | Required | Secret | Description | |----------|------|---------|----------|--------|-------------| | `roomId` | ID | false | Yes | No | Reference to the room this message belongs to | | `senderId` | ID | false | No | No | Reference to the user who sent this message | | `senderName` | String | false | No | No | Display name of the sender (denormalized from user profile at send time) | | `senderAvatar` | String | false | No | No | Avatar URL of the sender (denormalized from user profile at send time) | | `messageType` | Enum | false | Yes | No | Content type discriminator for this message | | `content` | Object | false | Yes | No | Type-specific content payload (structure depends on messageType) | | `timestamp` | | false | No | No | Message creation time | | `status` | Enum | false | No | No | Message moderation status | | `reaction` | Object | false | No | No | Emoji reactions [{ emoji, userId, timestamp }] | * Required properties are mandatory for creating objects and must be provided in the request body if no default value, formula or session bind is set. ### Enum Properties Enum properties are defined with a set of allowed values, ensuring that only valid options can be assigned to them. The enum options value will be stored as strings in the database, but when a data object is created an additional property with the same name plus an idx suffix will be created, which will hold the index of the selected enum option. You can use the {fieldName_idx} property to sort by the enum value or when your enum options represent a hiyerarchy of values. In the frontend input components, enum type properties should only accept values from an option component that lists the enum options. - **messageType**: [text, system] - **status**: [pending, approved, rejected] ### Filter Properties `roomId` `senderId` `senderName` `senderAvatar` `messageType` `content` `timestamp` `status` `reaction` Filter properties are used to define parameters that can be used in query filters, allowing for dynamic data retrieval based on user input or predefined criteria. These properties are automatically mapped as API parameters in the listing API's. - **roomId**: ID has a filter named `roomId` - **senderId**: ID has a filter named `senderId` - **senderName**: String has a filter named `senderName` - **senderAvatar**: String has a filter named `senderAvatar` - **messageType**: Enum has a filter named `messageType` - **content**: Object has a filter named `content` - **timestamp**: has a filter named `timestamp` - **status**: Enum has a filter named `status` - **reaction**: Object has a filter named `reaction` ## LobbyChatHubModeration Data Object Auto-generated moderation DataObject for the lobbyChatHub RealtimeHub. Stores block and silence actions for room-level user moderation. ### LobbyChatHubModeration Data Object Properties LobbyChatHubModeration data object has got following properties that are represented as table fields in the database scheme. These properties don't stand just for data storage, but each may have different settings to manage the business logic. | Property | Type | IsArray | Required | Secret | Description | |----------|------|---------|----------|--------|-------------| | `roomId` | ID | false | Yes | No | Reference to the room where the moderation action applies | | `userId` | ID | false | Yes | No | The user who is blocked or silenced | | `action` | Enum | false | Yes | No | Moderation action type | | `reason` | Text | false | No | No | Optional reason for the moderation action | | `duration` | Integer | false | No | No | Duration in seconds. 0 means permanent | | `expiresAt` | | false | No | No | Expiry timestamp. Null means permanent | | `issuedBy` | ID | false | No | No | The moderator who issued the action | * Required properties are mandatory for creating objects and must be provided in the request body if no default value, formula or session bind is set. ### Enum Properties Enum properties are defined with a set of allowed values, ensuring that only valid options can be assigned to them. The enum options value will be stored as strings in the database, but when a data object is created an additional property with the same name plus an idx suffix will be created, which will hold the index of the selected enum option. You can use the {fieldName_idx} property to sort by the enum value or when your enum options represent a hiyerarchy of values. In the frontend input components, enum type properties should only accept values from an option component that lists the enum options. - **action**: [blocked, silenced] ### Relation Properties `roomId` Mindbricks supports relations between data objects, allowing you to define how objects are linked together. The relations may reference to a data object either in this service or in another service. Id the reference is remote, backend handles the relations through service communication or elastic search. These relations should be respected in the frontend so that instaead of showing the related objects id, the frontend should list human readable values from other data objects. If the relation points to another service, frontend should use the referenced service api in case it needs related data. The relation logic is montly handled in backend so the api responses feeds the frontend about the relational data. In mmost cases the api response will provide the relational data as well as the main one. In frontend, please ensure that, 1- instaead of these relational ids you show the main human readable field of the related target data (like name), 2- if this data object needs a user input of these relational ids, you should provide a combobox with the list of possible records or (a searchbox) to select with the realted target data object main human readable field. - **roomId**: ID Relation to `lobbyRoom`.id The target object is a parent object, meaning that the relation is a one-to-many relationship from target to this object. Required: Yes ### Filter Properties `roomId` `userId` `action` `reason` `duration` `expiresAt` `issuedBy` Filter properties are used to define parameters that can be used in query filters, allowing for dynamic data retrieval based on user input or predefined criteria. These properties are automatically mapped as API parameters in the listing API's. - **roomId**: ID has a filter named `roomId` - **userId**: ID has a filter named `userId` - **action**: Enum has a filter named `action` - **reason**: Text has a filter named `reason` - **duration**: Integer has a filter named `duration` - **expiresAt**: has a filter named `expiresAt` - **issuedBy**: ID has a filter named `issuedBy` ## Default CRUD APIs For each data object, the backend architect may designate **default APIs** for standard operations (create, update, delete, get, list). These are the APIs that frontend CRUD forms and AI agents should use for basic record management. If no default is explicitly set (`isDefaultApi`), the frontend generator auto-discovers the most general API for each operation. ### LobbyMessage Default APIs | Operation | API Name | Route | Explicitly Set | |-----------|----------|-------|----------------| | Create | `createLobbyMessage` | `/v1/lobbymessages` | Yes | | Update | `updateLobbyMessageModeration` | `/v1/lobbymessagemoderation/:lobbyMessageId` | Yes | | Delete | `deleteLobbyMessage` | `/v1/lobbymessages/:lobbyMessageId` | Yes | | Get | _none_ | - | Auto | | List | `listLobbyMessages` | `/v1/listlobbymessages/:roomId` | Yes | ### LobbyRoom Default APIs | Operation | API Name | Route | Explicitly Set | |-----------|----------|-------|----------------| | Create | `ensureLobbyRoom` | `/v1/ensurelobbyroom` | Auto | | Update | _none_ | - | Auto | | Delete | _none_ | - | Auto | | Get | _none_ | - | Auto | | List | `listLobbyRooms` | `/v1/listlobbyrooms/:roomId` | Auto | ### LobbyChatHubMessage Default APIs | Operation | API Name | Route | Explicitly Set | |-----------|----------|-------|----------------| | Create | _none_ | - | Auto | | Update | `updateLobbyChatHubMessage` | `/v1/v1/lobbyChatHub-messages/:id` | Yes | | Delete | `deleteLobbyChatHubMessage` | `/v1/v1/lobbyChatHub-messages/:id` | Yes | | Get | `getLobbyChatHubMessage` | `/v1/v1/lobbyChatHub-messages/:id` | Yes | | List | `listLobbyChatHubMessages` | `/v1/v1/lobbyChatHub-messages` | Yes | ### LobbyChatHubModeration Default APIs | Operation | API Name | Route | Explicitly Set | |-----------|----------|-------|----------------| | Create | _none_ | - | Auto | | Update | _none_ | - | Auto | | Delete | _none_ | - | Auto | | Get | _none_ | - | Auto | | List | _none_ | - | Auto | When building CRUD forms for a data object, use the default create/update APIs listed above. The form fields should correspond to the API's body parameters. For relation fields, render a dropdown loaded from the related object's list API using the display label property. ## API Reference ### `Create Lobbymessage` API **[Default create API]** — This is the designated default `create` API for the `lobbyMessage` data object. Frontend generators and AI agents should use this API for standard CRUD operations. Post a new lobby chat message. Enforces mute (mutedUntil > now), ensures message is not empty and under 500 chars. SenderId and senderDisplayName are populated from session. **API Frontend Description By The Backend Architect** - Attempts to send a message as a muted user yield an immediate error and UI block for sending. - Messages must be non-empty, max 500 chars. - Name shown is from session context at send time (persists if user later changes display name). - Guests allowed; no editing or "threading". - No images/files — plain text only. **Rest Route** The `createLobbyMessage` API REST controller can be triggered via the following route: `/v1/lobbymessages` **Rest Request Parameters** The `createLobbyMessage` api has got 8 regular request parameters | Parameter | Type | Required | Population | | ---------------------- | ---------------------- | -------- | ---------------------------- | | senderId | ID | true | request.body?.["senderId"] | | senderDisplayName | String | true | request.body?.["senderDisplayName"] | | content | String | true | request.body?.["content"] | | sentAt | Date | true | request.body?.["sentAt"] | | reportStatus | Enum | true | request.body?.["reportStatus"] | | mutedUntil | Date | false | request.body?.["mutedUntil"] | | removed | Boolean | true | request.body?.["removed"] | | roomId | String | true | request.body?.["roomId"] | **senderId** : User ID (guest or registered) who sent the message. References auth:user.id. **senderDisplayName** : Display name (from user fullname at send time; allows historical display even if name changes). **content** : Chat message body (limited at UI, backend-enforces not empty; max 500 chars). **sentAt** : UTC timestamp when message was sent. Used to enforce 24h retention and sorting. **reportStatus** : Moderation/report workflow state: none (default), reported (user), underReview (admin). **mutedUntil** : If set, the message sender is muted in the lobby until this timestamp. Only admins may set. Used with senderId for lookup on enforcement. **removed** : If true, message is hidden/removed by admin moderation (soft-remove). **roomId** : Daily room identifier (lobby-YYYY-MM-DD). Scopes message to that day. **REST Request** To access the api you can use the **REST** controller with the path **POST /v1/lobbymessages** ```js axios({ method: 'POST', url: '/v1/lobbymessages', data: { senderId:"ID", senderDisplayName:"String", content:"String", sentAt:"Date", reportStatus:"Enum", mutedUntil:"Date", removed:"Boolean", roomId:"String", }, params: { } }); ``` **REST Response** ```json { "status": "OK", "statusCode": "201", "elapsedMs": 126, "ssoTime": 120, "source": "db", "cacheKey": "hexCode", "userId": "ID", "sessionId": "ID", "requestId": "ID", "dataName": "lobbyMessage", "method": "POST", "action": "create", "appVersion": "Version", "rowCount": 1, "lobbyMessage": { "id": "ID", "senderId": "ID", "senderDisplayName": "String", "content": "String", "sentAt": "Date", "reportStatus": "Enum", "reportStatus_idx": "Integer", "mutedUntil": "Date", "removed": "Boolean", "roomId": "String", "recordVersion": "Integer", "createdAt": "Date", "updatedAt": "Date", "_owner": "ID", "isActive": true } } ``` ### `List Lobbymessages` API **[Default list API]** — This is the designated default `list` API for the `lobbyMessage` data object. Frontend generators and AI agents should use this API for standard CRUD operations. Fetch latest lobby chat messages from the last 24 hours (not removed). Sorted sentAt desc. Paginated by default (50 per page). **API Frontend Description By The Backend Architect** - Displays newest messages first (descending by sentAt). - Returns only unremoved messages from last 24h. - Loading more (scroll/pagination) only fetches within valid 24h window. - Guests and registered users can access. - If no messages available, renders empty chat UI. - Default page size: 50. **Rest Route** The `listLobbyMessages` API REST controller can be triggered via the following route: `/v1/listlobbymessages/:roomId` **Rest Request Parameters** The `listLobbyMessages` api has got 1 regular request parameter | Parameter | Type | Required | Population | | ---------------------- | ---------------------- | -------- | ---------------------------- | | roomId | String | true | request.params?.["roomId"] | **roomId** : Daily room identifier (lobby-YYYY-MM-DD). Scopes message to that day.. The parameter is used to query data. **REST Request** To access the api you can use the **REST** controller with the path **GET /v1/listlobbymessages/:roomId** ```js axios({ method: 'GET', url: `/v1/listlobbymessages/${roomId}`, data: { }, params: { } }); ``` **REST Response** This route's response is constrained to a select list of properties, and therefore does not encompass all attributes of the resource. ```json { "status": "OK", "statusCode": "200", "elapsedMs": 126, "ssoTime": 120, "source": "db", "cacheKey": "hexCode", "userId": "ID", "sessionId": "ID", "requestId": "ID", "dataName": "lobbyMessages", "method": "GET", "action": "list", "appVersion": "Version", "rowCount": "\"Number\"", "lobbyMessages": [ { "isActive": true }, {}, {} ], "paging": { "pageNumber": "Number", "pageRowCount": "NUmber", "totalRowCount": "Number", "pageCount": "Number" }, "filters": [], "uiPermissions": [] } ``` ### `Update Lobbymessagemoderation` API **[Default update API]** — This is the designated default `update` API for the `lobbyMessage` data object. Frontend generators and AI agents should use this API for standard CRUD operations. Update message for moderation: only admins may set removed (true), mutedUntil, or set reportStatus to underReview. All users may set reportStatus to reported on a message they wish to report. Message owner may not update content or displayName. **API Frontend Description By The Backend Architect** - If admin sets removed, UI and API should treat as deleted for all users. - Admins can mute a sender (sets mutedUntil on relevant messages; for send-prevention, check most recent value). - Users may only set reportStatus to 'reported' for reporting flows, only once per message. Duplication is tolerated silently. - No editing of content allowed. **Rest Route** The `updateLobbyMessageModeration` API REST controller can be triggered via the following route: `/v1/lobbymessagemoderation/:lobbyMessageId` **Rest Request Parameters** The `updateLobbyMessageModeration` api has got 5 regular request parameters | Parameter | Type | Required | Population | | ---------------------- | ---------------------- | -------- | ---------------------------- | | lobbyMessageId | ID | true | request.params?.["lobbyMessageId"] | | reportStatus | Enum | false | request.body?.["reportStatus"] | | mutedUntil | Date | false | request.body?.["mutedUntil"] | | removed | Boolean | false | request.body?.["removed"] | | roomId | String | false | request.body?.["roomId"] | **lobbyMessageId** : This id paremeter is used to select the required data object that will be updated **reportStatus** : Moderation/report workflow state: none (default), reported (user), underReview (admin). **mutedUntil** : If set, the message sender is muted in the lobby until this timestamp. Only admins may set. Used with senderId for lookup on enforcement. **removed** : If true, message is hidden/removed by admin moderation (soft-remove). **roomId** : Daily room identifier (lobby-YYYY-MM-DD). Scopes message to that day. **REST Request** To access the api you can use the **REST** controller with the path **PATCH /v1/lobbymessagemoderation/:lobbyMessageId** ```js axios({ method: 'PATCH', url: `/v1/lobbymessagemoderation/${lobbyMessageId}`, data: { reportStatus:"Enum", mutedUntil:"Date", removed:"Boolean", roomId:"String", }, params: { } }); ``` **REST Response** ```json { "status": "OK", "statusCode": "200", "elapsedMs": 126, "ssoTime": 120, "source": "db", "cacheKey": "hexCode", "userId": "ID", "sessionId": "ID", "requestId": "ID", "dataName": "lobbyMessage", "method": "PATCH", "action": "update", "appVersion": "Version", "rowCount": 1, "lobbyMessage": { "id": "ID", "senderId": "ID", "senderDisplayName": "String", "content": "String", "sentAt": "Date", "reportStatus": "Enum", "reportStatus_idx": "Integer", "mutedUntil": "Date", "removed": "Boolean", "roomId": "String", "recordVersion": "Integer", "createdAt": "Date", "updatedAt": "Date", "_owner": "ID", "isActive": true } } ``` ### `Delete Lobbymessage` API **[Default delete API]** — This is the designated default `delete` API for the `lobbyMessage` data object. Frontend generators and AI agents should use this API for standard CRUD operations. Physical delete of a lobby message (should only be possible for admin batch/cleanup or hard moderation). In practice, most moderation is via `removed:true`. **API Frontend Description By The Backend Architect** - Admin-only; normal users cannot hard-delete any message. - UI presents "removed" status using removed:true; only admin 'expunge' actually deletes DB row. - Cron clean/purge uses this API to destroy messages older than 24h. **Rest Route** The `deleteLobbyMessage` API REST controller can be triggered via the following route: `/v1/lobbymessages/:lobbyMessageId` **Rest Request Parameters** The `deleteLobbyMessage` api has got 1 regular request parameter | Parameter | Type | Required | Population | | ---------------------- | ---------------------- | -------- | ---------------------------- | | lobbyMessageId | ID | true | request.params?.["lobbyMessageId"] | **lobbyMessageId** : This id paremeter is used to select the required data object that will be deleted **REST Request** To access the api you can use the **REST** controller with the path **DELETE /v1/lobbymessages/:lobbyMessageId** ```js axios({ method: 'DELETE', url: `/v1/lobbymessages/${lobbyMessageId}`, data: { }, params: { } }); ``` **REST Response** ```json { "status": "OK", "statusCode": "200", "elapsedMs": 126, "ssoTime": 120, "source": "db", "cacheKey": "hexCode", "userId": "ID", "sessionId": "ID", "requestId": "ID", "dataName": "lobbyMessage", "method": "DELETE", "action": "delete", "appVersion": "Version", "rowCount": 1, "lobbyMessage": { "id": "ID", "senderId": "ID", "senderDisplayName": "String", "content": "String", "sentAt": "Date", "reportStatus": "Enum", "reportStatus_idx": "Integer", "mutedUntil": "Date", "removed": "Boolean", "roomId": "String", "recordVersion": "Integer", "createdAt": "Date", "updatedAt": "Date", "_owner": "ID", "isActive": false } } ``` ### `Ensure Lobbyroom` API **Rest Route** The `ensureLobbyRoom` API REST controller can be triggered via the following route: `/v1/ensurelobbyroom` **Rest Request Parameters** The `ensureLobbyRoom` api has got 1 regular request parameter | Parameter | Type | Required | Population | | ---------------------- | ---------------------- | -------- | ---------------------------- | | roomId | String | true | request.body?.["roomId"] | **roomId** : Room identifier, e.g. lobby-2026-03-10 **REST Request** To access the api you can use the **REST** controller with the path **POST /v1/ensurelobbyroom** ```js axios({ method: 'POST', url: '/v1/ensurelobbyroom', data: { roomId:"String", }, params: { } }); ``` **REST Response** ```json { "status": "OK", "statusCode": "201", "elapsedMs": 126, "ssoTime": 120, "source": "db", "cacheKey": "hexCode", "userId": "ID", "sessionId": "ID", "requestId": "ID", "dataName": "lobbyRoom", "method": "POST", "action": "create", "appVersion": "Version", "rowCount": 1, "lobbyRoom": { "id": "ID", "roomId": "String", "isActive": true, "recordVersion": "Integer", "createdAt": "Date", "updatedAt": "Date", "_owner": "ID" } } ``` ### `List Lobbyrooms` API **Rest Route** The `listLobbyRooms` API REST controller can be triggered via the following route: `/v1/listlobbyrooms/:roomId` **Rest Request Parameters** The `listLobbyRooms` api has got 1 regular request parameter | Parameter | Type | Required | Population | | ---------------------- | ---------------------- | -------- | ---------------------------- | | roomId | String | true | request.params?.["roomId"] | **roomId** : Room identifier, e.g. lobby-2026-03-10. The parameter is used to query data. **REST Request** To access the api you can use the **REST** controller with the path **GET /v1/listlobbyrooms/:roomId** ```js axios({ method: 'GET', url: `/v1/listlobbyrooms/${roomId}`, data: { }, params: { } }); ``` **REST Response** ```json { "status": "OK", "statusCode": "200", "elapsedMs": 126, "ssoTime": 120, "source": "db", "cacheKey": "hexCode", "userId": "ID", "sessionId": "ID", "requestId": "ID", "dataName": "lobbyRooms", "method": "GET", "action": "list", "appVersion": "Version", "rowCount": "\"Number\"", "lobbyRooms": [ { "id": "ID", "roomId": "String", "isActive": true, "recordVersion": "Integer", "createdAt": "Date", "updatedAt": "Date", "_owner": "ID" }, {}, {} ], "paging": { "pageNumber": "Number", "pageRowCount": "NUmber", "totalRowCount": "Number", "pageCount": "Number" }, "filters": [], "uiPermissions": [] } ``` ### `List Lobbychathubmessages` API **[Default list API]** — This is the designated default `list` API for the `lobbyChatHubMessage` data object. Frontend generators and AI agents should use this API for standard CRUD operations. List messages in a lobbyChatHub hub room. Accessible by admins and room participants. **Rest Route** The `listLobbyChatHubMessages` API REST controller can be triggered via the following route: `/v1/v1/lobbyChatHub-messages` **Rest Request Parameters** **Filter Parameters** The `listLobbyChatHubMessages` api supports 9 optional filter parameters for filtering list results: **roomId** (`ID`): Reference to the room this message belongs to - Single: `?roomId=` - Multiple: `?roomId=&roomId=` - Null: `?roomId=null` **senderId** (`ID`): Reference to the user who sent this message - Single: `?senderId=` - Multiple: `?senderId=&senderId=` - Null: `?senderId=null` **senderName** (`String`): Display name of the sender (denormalized from user profile at send time) - Single (partial match, case-insensitive): `?senderName=` - Multiple: `?senderName=&senderName=` - Null: `?senderName=null` **senderAvatar** (`String`): Avatar URL of the sender (denormalized from user profile at send time) - Single (partial match, case-insensitive): `?senderAvatar=` - Multiple: `?senderAvatar=&senderAvatar=` - Null: `?senderAvatar=null` **messageType** (`Enum`): Content type discriminator for this message - Single: `?messageType=` (case-insensitive) - Multiple: `?messageType=&messageType=` - Null: `?messageType=null` **content** (`Object`): Type-specific content payload (structure depends on messageType) - Single: `?content=` - Multiple: `?content=&content=` - Null: `?content=null` **timestamp** (`String`): Message creation time - Single (partial match, case-insensitive): `?timestamp=` - Multiple: `?timestamp=×tamp=` - Null: `?timestamp=null` **status** (`Enum`): Message moderation status - Single: `?status=` (case-insensitive) - Multiple: `?status=&status=` - Null: `?status=null` **reaction** (`Object`): Emoji reactions [{ emoji, userId, timestamp }] - Single: `?reaction=` - Multiple: `?reaction=&reaction=` - Null: `?reaction=null` **REST Request** To access the api you can use the **REST** controller with the path **GET /v1/v1/lobbyChatHub-messages** ```js axios({ method: 'GET', url: '/v1/v1/lobbyChatHub-messages', data: { }, params: { // Filter parameters (see Filter Parameters section above) // roomId: '' // Filter by roomId // senderId: '' // Filter by senderId // senderName: '' // Filter by senderName // senderAvatar: '' // Filter by senderAvatar // messageType: '' // Filter by messageType // content: '' // Filter by content // timestamp: '' // Filter by timestamp // status: '' // Filter by status // reaction: '' // Filter by reaction } }); ``` **REST Response** ```json { "status": "OK", "statusCode": "200", "elapsedMs": 126, "ssoTime": 120, "source": "db", "cacheKey": "hexCode", "userId": "ID", "sessionId": "ID", "requestId": "ID", "dataName": "lobbyChatHubMessages", "method": "GET", "action": "list", "appVersion": "Version", "rowCount": "\"Number\"", "lobbyChatHubMessages": [ { "id": "ID", "roomId": "ID", "senderId": "ID", "senderName": "String", "senderAvatar": "String", "messageType": "Enum", "messageType_idx": "Integer", "content": "Object", "timestamp": null, "status": "Enum", "status_idx": "Integer", "reaction": "Object", "isActive": true, "recordVersion": "Integer", "createdAt": "Date", "updatedAt": "Date", "_owner": "ID" }, {}, {} ], "paging": { "pageNumber": "Number", "pageRowCount": "NUmber", "totalRowCount": "Number", "pageCount": "Number" }, "filters": [], "uiPermissions": [] } ``` ### `Get Lobbychathubmessage` API **[Default get API]** — This is the designated default `get` API for the `lobbyChatHubMessage` data object. Frontend generators and AI agents should use this API for standard CRUD operations. Get a single lobbyChatHub hub message by ID. **Rest Route** The `getLobbyChatHubMessage` API REST controller can be triggered via the following route: `/v1/v1/lobbyChatHub-messages/:id` **Rest Request Parameters** The `getLobbyChatHubMessage` api has got 2 regular request parameters | Parameter | Type | Required | Population | | ---------------------- | ---------------------- | -------- | ---------------------------- | | lobbyChatHubMessageId | ID | true | request.params?.["lobbyChatHubMessageId"] | | id | String | true | request.params?.["id"] | **lobbyChatHubMessageId** : This id paremeter is used to query the required data object. **id** : This parameter will be used to select the data object that is queried **REST Request** To access the api you can use the **REST** controller with the path **GET /v1/v1/lobbyChatHub-messages/:id** ```js axios({ method: 'GET', url: `/v1/v1/lobbyChatHub-messages/${id}`, data: { }, params: { } }); ``` **REST Response** ```json { "status": "OK", "statusCode": "200", "elapsedMs": 126, "ssoTime": 120, "source": "db", "cacheKey": "hexCode", "userId": "ID", "sessionId": "ID", "requestId": "ID", "dataName": "lobbyChatHubMessage", "method": "GET", "action": "get", "appVersion": "Version", "rowCount": 1, "lobbyChatHubMessage": { "id": "ID", "roomId": "ID", "senderId": "ID", "senderName": "String", "senderAvatar": "String", "messageType": "Enum", "messageType_idx": "Integer", "content": "Object", "timestamp": null, "status": "Enum", "status_idx": "Integer", "reaction": "Object", "isActive": true, "recordVersion": "Integer", "createdAt": "Date", "updatedAt": "Date", "_owner": "ID" } } ``` ### `Delete Lobbychathubmessage` API **[Default delete API]** — This is the designated default `delete` API for the `lobbyChatHubMessage` data object. Frontend generators and AI agents should use this API for standard CRUD operations. Delete a lobbyChatHub hub message. Admins can delete any message; users can delete their own. **Rest Route** The `deleteLobbyChatHubMessage` API REST controller can be triggered via the following route: `/v1/v1/lobbyChatHub-messages/:id` **Rest Request Parameters** The `deleteLobbyChatHubMessage` api has got 2 regular request parameters | Parameter | Type | Required | Population | | ---------------------- | ---------------------- | -------- | ---------------------------- | | lobbyChatHubMessageId | ID | true | request.params?.["lobbyChatHubMessageId"] | | id | String | true | request.params?.["id"] | **lobbyChatHubMessageId** : This id paremeter is used to select the required data object that will be deleted **id** : This parameter will be used to select the data object that want to be deleted **REST Request** To access the api you can use the **REST** controller with the path **DELETE /v1/v1/lobbyChatHub-messages/:id** ```js axios({ method: 'DELETE', url: `/v1/v1/lobbyChatHub-messages/${id}`, data: { }, params: { } }); ``` **REST Response** ```json { "status": "OK", "statusCode": "200", "elapsedMs": 126, "ssoTime": 120, "source": "db", "cacheKey": "hexCode", "userId": "ID", "sessionId": "ID", "requestId": "ID", "dataName": "lobbyChatHubMessage", "method": "DELETE", "action": "delete", "appVersion": "Version", "rowCount": 1, "lobbyChatHubMessage": { "id": "ID", "roomId": "ID", "senderId": "ID", "senderName": "String", "senderAvatar": "String", "messageType": "Enum", "messageType_idx": "Integer", "content": "Object", "timestamp": null, "status": "Enum", "status_idx": "Integer", "reaction": "Object", "isActive": false, "recordVersion": "Integer", "createdAt": "Date", "updatedAt": "Date", "_owner": "ID" } } ``` ### `Update Lobbychathubmessage` API **[Default update API]** — This is the designated default `update` API for the `lobbyChatHubMessage` data object. Frontend generators and AI agents should use this API for standard CRUD operations. Update a lobbyChatHub hub message content. Only the message sender or admins can edit. **Rest Route** The `updateLobbyChatHubMessage` API REST controller can be triggered via the following route: `/v1/v1/lobbyChatHub-messages/:id` **Rest Request Parameters** The `updateLobbyChatHubMessage` api has got 5 regular request parameters | Parameter | Type | Required | Population | | ---------------------- | ---------------------- | -------- | ---------------------------- | | lobbyChatHubMessageId | ID | true | request.params?.["lobbyChatHubMessageId"] | | content | Object | false | request.body?.["content"] | | status | Enum | false | request.body?.["status"] | | reaction | Object | false | request.body?.["reaction"] | | id | String | true | request.params?.["id"] | **lobbyChatHubMessageId** : This id paremeter is used to select the required data object that will be updated **content** : Type-specific content payload (structure depends on messageType) **status** : Message moderation status **reaction** : Emoji reactions [{ emoji, userId, timestamp }] **id** : This parameter will be used to select the data object that want to be updated **REST Request** To access the api you can use the **REST** controller with the path **PATCH /v1/v1/lobbyChatHub-messages/:id** ```js axios({ method: 'PATCH', url: `/v1/v1/lobbyChatHub-messages/${id}`, data: { content:"Object", status:"Enum", reaction:"Object", }, params: { } }); ``` **REST Response** ```json { "status": "OK", "statusCode": "200", "elapsedMs": 126, "ssoTime": 120, "source": "db", "cacheKey": "hexCode", "userId": "ID", "sessionId": "ID", "requestId": "ID", "dataName": "lobbyChatHubMessage", "method": "PATCH", "action": "update", "appVersion": "Version", "rowCount": 1, "lobbyChatHubMessage": { "id": "ID", "roomId": "ID", "senderId": "ID", "senderName": "String", "senderAvatar": "String", "messageType": "Enum", "messageType_idx": "Integer", "content": "Object", "timestamp": null, "status": "Enum", "status_idx": "Integer", "reaction": "Object", "isActive": true, "recordVersion": "Integer", "createdAt": "Date", "updatedAt": "Date", "_owner": "ID" } } ``` **After this prompt, the user may give you new instructions to update the output of this prompt or provide subsequent prompts about the project.**