@xfloor/floor-memory-sdk-ts 1.0.3 → 1.0.5

package/dist/apis/EventApi.js

@@ -3,7 +3,9 @@
 /* eslint-disable */
 /**
  * Floor Memory
- * The set APIs are used to develop Floor pds which can be used as their personal assistants.   This set of APIs are divided into two parts.  - Memory and  - Registration.   The developer has two ways of using the APIs for the app development. Developer can choose to the  Registration APIs for using the existing xfloor infracture or can implement custom Registration process. In the case of custom registration process, the developer is bound to provide proper authentication mechanisms and then send the user information to xlfoor.
+ * The set APIs are used to develop Floor pds which can be used as their personal assistants. This set of APIs are divided into two parts.
+ * - Memory and
+ * - Registration. The developer has two ways of using the APIs for the app development. Developer can choose to the Registration APIs for using the existing xfloor infracture or can implement custom Registration process. In the case of custom registration process, the developer is bound to provide proper authentication mechanisms and then send the user information to xlfoor.
  *
  * The version of the OpenAPI document: 1.0.0
  * Contact: contact@ipomo.in
@@ -76,7 +78,7 @@ var EventApi = /** @class */ (function (_super) {
         return _super !== null && _super.apply(this, arguments) || this;
     }
     /**
-     * Posts into the given floor_id. This is asynchronous ingestion. 200 OK means queued, not immediately retrievable. This API allows a user to **post personal content into their POD (Personal Object Database)**. The posted content is stored under a specified **floor**, embedded by the platform, and made available for **semantic querying, conversational retrieval, and memory-based interactions**.  It is primarily used to:  * Save reminders, notes, writeups, or personal knowledge * Upload content that the user wants the system to remember * Add information that should later be discoverable via conversational queries  The content may consist of **text only** or **text combined with one or more media files**.  ---  ## **Key Capabilities**  * Stores user-generated content inside a specific floor * Supports **multi-modal inputs** (text + media) * Automatically embeds content for semantic search * Makes content available to:    * `/agent/memory/query`   * conversational agents   * future recall and analytics * Associates content with user, block, and application context  ---  ## **Authentication**  * Requires a valid, authenticated `user_id` * The calling application is responsible for user authentication * `app_id` identifies the application context  ---  ## **Request Type**  **Content-Type:** `multipart/form-data`  ---  ## **Request Parameters**  ### **1. Files (Optional)**  | Field   | Type   | Required | Description                                                           | | ------- | ------ | -------- | --------------------------------------------------------------------- | | `files` | file[] | Optional | Media files to attach to the content. Multiple files may be uploaded. |  **Supported formats include (but are not limited to):**  * Images: `jpg`, `png` * Audio: `mp3` * Documents: `pdf` * Video: `mp4`  These files are processed and embedded along with the textual content where applicable.  ---  ### **2. Input Information (Required)**  | Field        | Type          | Required | Description                                                       | | ------------ | ------------- | -------- | ----------------------------------------------------------------- | | `input_info` | string (JSON) | Yes      | JSON string containing metadata and textual content for the post. |  ---  ## **`input_info` Structure**  ```json {   \"floor_id\": \"my_floor\",   \"BID\": \"17845683456\",   \"user_id\": \"145623907625\",   \"title\": \"My floor\",   \"description\": \"My floor details\",   \"app_id\": \"165434879028\" } ```  ---  ### **Field Descriptions**  | Field         | Type   | Required | Description                                                                        | | ------------- | ------ | -------- | ---------------------------------------------------------------------------------- | | `floor_id`    | string | Yes      | Identifier of the user’s floor (POD) where the content will be stored.             | | `block_type`  | string | Yes      | Type of block under which the content is categorized (e.g., post, note, reminder). | | `BID`         | string | Yes      | Block identifier associated with this content.                                     | | `user_id`     | string | Yes      | Unique identifier of the user posting the content.                                 | | `title`       | string | Optional | Title or short heading for the content.                                            | | `description` | string | Yes      | Main textual content to be stored and embedded.                                    | | `app_id`      | string | Optional | Identifier of the calling application.                                             |  ---  ## **Behavior**  1. The API validates the user and floor context. 2. Textual content (`title` and `description`) is ingested. 3. Attached media files are processed and linked to the content. 4. Embeddings are generated for:     * Text    * Supported media (where applicable) 5. The content becomes part of the user’s **personal memory store**. 6. The stored data is immediately available for querying and conversational retrieval.  ---  ## **Successful Response**  On success, the API confirms that:  * The content has been stored * Embeddings have been generated * The memory item is available for future queries  A success status and reference identifiers are returned.  ---  ## **Error Handling**  The API may return errors if:  * Required fields are missing (`floor_id`, `user_id`, `description`) * Unsupported file formats are uploaded * The user does not have access to the specified floor * The request payload is malformed * Internal embedding or storage operations fail  ---  ## **Typical Use Cases**  * Saving personal reminders * Posting notes or observations * Uploading documents for future reference * Creating a personal knowledge base * Feeding data into conversational agents  ---  ## **One-Line Summary**  > Stores user-generated text and media into a personal POD, embeds it for semantic search, and makes it available for conversational querying.  ⚠️ Content Ingestion is Asynchronous  The Create Event API queues content for processing. A successful response indicates **acceptance**, not availability.  Newly ingested content may take time to become searchable via the Query API.
+     * ## Create Event (Content Ingestion)  Posts content into the specified `floor_id`. This API performs **asynchronous ingestion** — a `200 OK` response means the content has been **accepted and queued**, not immediately retrievable.  This API allows a user to **post personal content into their POD (Personal Object Database)**.  The posted content is stored under a specified **floor**, embedded by the platform, and made available for **semantic querying, conversational retrieval, and memory-based interactions** once processing completes.  It is primarily used to:  * Save reminders, notes, write-ups, or personal knowledge * Upload content the user wants the system to remember * Add information that should later be discoverable via conversational queries  The content may consist of **text only** or **text combined with one or more media files**.  ---  ## Key Capabilities  * Stores user-generated content inside a specific floor * Supports **multi-modal inputs** (text + media) * Automatically embeds content for semantic search * Makes content available to:    * `/agent/memory/query`   * conversational agents   * future recall and analytics * Associates content with **user**, **block**, and **application** context (when provided)  ---  ## Authentication  * Requires a valid, authenticated `user_id` * The calling application is responsible for user authentication * `app_id` identifies the application context  ---  ## Request Type  **Content-Type:** `multipart/form-data`  ---  ## Request Parameters  ### 1. Files (Optional)  | Field   | Type     | Required | Description                                                           | | ------- | -------- | -------- | --------------------------------------------------------------------- | | `files` | `file[]` | Optional | Media files to attach to the content. Multiple files may be uploaded. |  **Supported formats include (but are not limited to):**  * Images: `jpg`, `png` * Audio: `mp3` * Documents: `pdf` * Video: `mp4`  These files are processed and embedded along with the textual content where applicable.  ---  ### 2. Input Information (Required)  | Field        | Type            | Required | Description                                                       | | ------------ | --------------- | -------- | ----------------------------------------------------------------- | | `input_info` | `string (JSON)` | Yes      | JSON string containing metadata and textual content for the post. |  ---  ## `input_info` Structure  ```json {   \"floor_id\": \"my_floor\",   \"block_id\": \"17845683456\",   \"block_type\": \"post\",   \"user_id\": \"145623907625\",   \"title\": \"My note\",   \"description\": \"Things I should remember\",   \"app_id\": \"165434879028\" } ```  ---  ## Field Descriptions  | Field         | Type     | Required | Description                                                                                               | | ------------- | -------- | -------- | --------------------------------------------------------------------------------------------------------- | | `floor_id`    | `string` | Yes      | Identifier of the user’s floor (POD) where the content will be stored.                                    | | `block_id`    | `string` | Optional | Identifier of the block within the floor used to group or categorize content.                             | | `block_type`  | `string` | Optional | Logical category of the content (e.g., `post`, `note`, `reminder`). Used for routing and UI organization. | | `user_id`     | `string` | Yes      | Unique identifier of the user posting the content.                                                        | | `title`       | `string` | Optional | Short title or heading for the content.                                                                   | | `description` | `string` | Yes      | Main textual content to be stored and embedded.                                                           | | `app_id`      | `string` | Optional | Identifier of the calling application context.                                                            |  ---  ## Behavior  1. The API validates the user and floor context. 2. Textual content (`title` and `description`) is ingested. 3. Attached media files (if any) are processed and linked to the content. 4. Embeddings are generated for:     * text    * supported media (where applicable) 5. The content becomes part of the user’s **personal memory store (POD)**. 6. Once background processing completes, the content becomes available for:     * semantic search    * conversational retrieval    * memory-based interactions  ---  ## Successful Response  On success, the API confirms that:  * The content has been **accepted** * Processing has been **queued** * Reference identifiers are returned  > A successful response indicates **acceptance**, not immediate availability.  ---  ## Error Handling  The API may return errors if:  * Required fields are missing (`floor_id`, `user_id`, `description`) * Uploaded files use unsupported formats * The user does not have access to the specified floor * The request payload is malformed * Internal embedding or storage operations fail  ---  ## Typical Use Cases  * Saving personal reminders * Posting notes or observations * Uploading documents for later recall * Building a personal knowledge base * Feeding content into conversational agents  ---  ## ⚠️ Asynchronous Ingestion Notice  Content ingestion is **asynchronous**.  A `200 OK` response means the request was **successfully queued**. Newly ingested content may take time to become searchable via the Query API.  Use **Recent Events** or retry queries after a short delay to confirm availability.  ---  ## One-Line Summary  > Stores user-generated text and media into a personal POD, embeds it asynchronously, and makes it available for semantic and conversational querying.  If you want, next I can:  * align this **exactly** with the OpenAPI schema fields * generate **JS / TS / Python / Java snippets** using this definition * add **state diagrams** (queued → processing → searchable) for docs
      * Create Event (Post Content)
      */
     EventApi.prototype.eventRaw = function (requestParameters, initOverrides) {
@@ -135,7 +137,7 @@ var EventApi = /** @class */ (function (_super) {
         });
     };
     /**
-     * Posts into the given floor_id. This is asynchronous ingestion. 200 OK means queued, not immediately retrievable. This API allows a user to **post personal content into their POD (Personal Object Database)**. The posted content is stored under a specified **floor**, embedded by the platform, and made available for **semantic querying, conversational retrieval, and memory-based interactions**.  It is primarily used to:  * Save reminders, notes, writeups, or personal knowledge * Upload content that the user wants the system to remember * Add information that should later be discoverable via conversational queries  The content may consist of **text only** or **text combined with one or more media files**.  ---  ## **Key Capabilities**  * Stores user-generated content inside a specific floor * Supports **multi-modal inputs** (text + media) * Automatically embeds content for semantic search * Makes content available to:    * `/agent/memory/query`   * conversational agents   * future recall and analytics * Associates content with user, block, and application context  ---  ## **Authentication**  * Requires a valid, authenticated `user_id` * The calling application is responsible for user authentication * `app_id` identifies the application context  ---  ## **Request Type**  **Content-Type:** `multipart/form-data`  ---  ## **Request Parameters**  ### **1. Files (Optional)**  | Field   | Type   | Required | Description                                                           | | ------- | ------ | -------- | --------------------------------------------------------------------- | | `files` | file[] | Optional | Media files to attach to the content. Multiple files may be uploaded. |  **Supported formats include (but are not limited to):**  * Images: `jpg`, `png` * Audio: `mp3` * Documents: `pdf` * Video: `mp4`  These files are processed and embedded along with the textual content where applicable.  ---  ### **2. Input Information (Required)**  | Field        | Type          | Required | Description                                                       | | ------------ | ------------- | -------- | ----------------------------------------------------------------- | | `input_info` | string (JSON) | Yes      | JSON string containing metadata and textual content for the post. |  ---  ## **`input_info` Structure**  ```json {   \"floor_id\": \"my_floor\",   \"BID\": \"17845683456\",   \"user_id\": \"145623907625\",   \"title\": \"My floor\",   \"description\": \"My floor details\",   \"app_id\": \"165434879028\" } ```  ---  ### **Field Descriptions**  | Field         | Type   | Required | Description                                                                        | | ------------- | ------ | -------- | ---------------------------------------------------------------------------------- | | `floor_id`    | string | Yes      | Identifier of the user’s floor (POD) where the content will be stored.             | | `block_type`  | string | Yes      | Type of block under which the content is categorized (e.g., post, note, reminder). | | `BID`         | string | Yes      | Block identifier associated with this content.                                     | | `user_id`     | string | Yes      | Unique identifier of the user posting the content.                                 | | `title`       | string | Optional | Title or short heading for the content.                                            | | `description` | string | Yes      | Main textual content to be stored and embedded.                                    | | `app_id`      | string | Optional | Identifier of the calling application.                                             |  ---  ## **Behavior**  1. The API validates the user and floor context. 2. Textual content (`title` and `description`) is ingested. 3. Attached media files are processed and linked to the content. 4. Embeddings are generated for:     * Text    * Supported media (where applicable) 5. The content becomes part of the user’s **personal memory store**. 6. The stored data is immediately available for querying and conversational retrieval.  ---  ## **Successful Response**  On success, the API confirms that:  * The content has been stored * Embeddings have been generated * The memory item is available for future queries  A success status and reference identifiers are returned.  ---  ## **Error Handling**  The API may return errors if:  * Required fields are missing (`floor_id`, `user_id`, `description`) * Unsupported file formats are uploaded * The user does not have access to the specified floor * The request payload is malformed * Internal embedding or storage operations fail  ---  ## **Typical Use Cases**  * Saving personal reminders * Posting notes or observations * Uploading documents for future reference * Creating a personal knowledge base * Feeding data into conversational agents  ---  ## **One-Line Summary**  > Stores user-generated text and media into a personal POD, embeds it for semantic search, and makes it available for conversational querying.  ⚠️ Content Ingestion is Asynchronous  The Create Event API queues content for processing. A successful response indicates **acceptance**, not availability.  Newly ingested content may take time to become searchable via the Query API.
+     * ## Create Event (Content Ingestion)  Posts content into the specified `floor_id`. This API performs **asynchronous ingestion** — a `200 OK` response means the content has been **accepted and queued**, not immediately retrievable.  This API allows a user to **post personal content into their POD (Personal Object Database)**.  The posted content is stored under a specified **floor**, embedded by the platform, and made available for **semantic querying, conversational retrieval, and memory-based interactions** once processing completes.  It is primarily used to:  * Save reminders, notes, write-ups, or personal knowledge * Upload content the user wants the system to remember * Add information that should later be discoverable via conversational queries  The content may consist of **text only** or **text combined with one or more media files**.  ---  ## Key Capabilities  * Stores user-generated content inside a specific floor * Supports **multi-modal inputs** (text + media) * Automatically embeds content for semantic search * Makes content available to:    * `/agent/memory/query`   * conversational agents   * future recall and analytics * Associates content with **user**, **block**, and **application** context (when provided)  ---  ## Authentication  * Requires a valid, authenticated `user_id` * The calling application is responsible for user authentication * `app_id` identifies the application context  ---  ## Request Type  **Content-Type:** `multipart/form-data`  ---  ## Request Parameters  ### 1. Files (Optional)  | Field   | Type     | Required | Description                                                           | | ------- | -------- | -------- | --------------------------------------------------------------------- | | `files` | `file[]` | Optional | Media files to attach to the content. Multiple files may be uploaded. |  **Supported formats include (but are not limited to):**  * Images: `jpg`, `png` * Audio: `mp3` * Documents: `pdf` * Video: `mp4`  These files are processed and embedded along with the textual content where applicable.  ---  ### 2. Input Information (Required)  | Field        | Type            | Required | Description                                                       | | ------------ | --------------- | -------- | ----------------------------------------------------------------- | | `input_info` | `string (JSON)` | Yes      | JSON string containing metadata and textual content for the post. |  ---  ## `input_info` Structure  ```json {   \"floor_id\": \"my_floor\",   \"block_id\": \"17845683456\",   \"block_type\": \"post\",   \"user_id\": \"145623907625\",   \"title\": \"My note\",   \"description\": \"Things I should remember\",   \"app_id\": \"165434879028\" } ```  ---  ## Field Descriptions  | Field         | Type     | Required | Description                                                                                               | | ------------- | -------- | -------- | --------------------------------------------------------------------------------------------------------- | | `floor_id`    | `string` | Yes      | Identifier of the user’s floor (POD) where the content will be stored.                                    | | `block_id`    | `string` | Optional | Identifier of the block within the floor used to group or categorize content.                             | | `block_type`  | `string` | Optional | Logical category of the content (e.g., `post`, `note`, `reminder`). Used for routing and UI organization. | | `user_id`     | `string` | Yes      | Unique identifier of the user posting the content.                                                        | | `title`       | `string` | Optional | Short title or heading for the content.                                                                   | | `description` | `string` | Yes      | Main textual content to be stored and embedded.                                                           | | `app_id`      | `string` | Optional | Identifier of the calling application context.                                                            |  ---  ## Behavior  1. The API validates the user and floor context. 2. Textual content (`title` and `description`) is ingested. 3. Attached media files (if any) are processed and linked to the content. 4. Embeddings are generated for:     * text    * supported media (where applicable) 5. The content becomes part of the user’s **personal memory store (POD)**. 6. Once background processing completes, the content becomes available for:     * semantic search    * conversational retrieval    * memory-based interactions  ---  ## Successful Response  On success, the API confirms that:  * The content has been **accepted** * Processing has been **queued** * Reference identifiers are returned  > A successful response indicates **acceptance**, not immediate availability.  ---  ## Error Handling  The API may return errors if:  * Required fields are missing (`floor_id`, `user_id`, `description`) * Uploaded files use unsupported formats * The user does not have access to the specified floor * The request payload is malformed * Internal embedding or storage operations fail  ---  ## Typical Use Cases  * Saving personal reminders * Posting notes or observations * Uploading documents for later recall * Building a personal knowledge base * Feeding content into conversational agents  ---  ## ⚠️ Asynchronous Ingestion Notice  Content ingestion is **asynchronous**.  A `200 OK` response means the request was **successfully queued**. Newly ingested content may take time to become searchable via the Query API.  Use **Recent Events** or retry queries after a short delay to confirm availability.  ---  ## One-Line Summary  > Stores user-generated text and media into a personal POD, embeds it asynchronously, and makes it available for semantic and conversational querying.  If you want, next I can:  * align this **exactly** with the OpenAPI schema fields * generate **JS / TS / Python / Java snippets** using this definition * add **state diagrams** (queued → processing → searchable) for docs
      * Create Event (Post Content)
      */
     EventApi.prototype.event = function (requestParameters, initOverrides) {

package/dist/apis/GetFloorInformationApi.d.ts

@@ -1,6 +1,8 @@
 /**
  * Floor Memory
- * The set APIs are used to develop Floor pds which can be used as their personal assistants.   This set of APIs are divided into two parts.  - Memory and  - Registration.   The developer has two ways of using the APIs for the app development. Developer can choose to the  Registration APIs for using the existing xfloor infracture or can implement custom Registration process. In the case of custom registration process, the developer is bound to provide proper authentication mechanisms and then send the user information to xlfoor.
+ * The set APIs are used to develop Floor pds which can be used as their personal assistants. This set of APIs are divided into two parts.
+ * - Memory and
+ * - Registration. The developer has two ways of using the APIs for the app development. Developer can choose to the Registration APIs for using the existing xfloor infracture or can implement custom Registration process. In the case of custom registration process, the developer is bound to provide proper authentication mechanisms and then send the user information to xlfoor.
  *
  * The version of the OpenAPI document: 1.0.0
  * Contact: contact@ipomo.in
@@ -21,12 +23,12 @@ export interface GetFloorInformationRequest {
  */
 export declare class GetFloorInformationApi extends runtime.BaseAPI {
     /**
-     * This API returns the **basic profile information of a floor**. It is used to fetch all essential metadata required to **render a floor landing page, header, or navigation context**.  The response includes:  * Floor identity and type * Ownership information relative to the requesting user * Floor metadata (title, description, avatar) * List of blocks available in the floor * App association (for pod / developer use cases)  This API does **not** return posts or content; it only provides **structural and descriptive information** about the floor.  ---  ## Typical Use Cases  * Render floor header (title, logo, description) * Decide UI permissions (owner vs non-owner) * Display available blocks (Feeds, Blog, Quiz, etc.) * Pod discovery or developer-managed floor rendering * Lightweight floor metadata fetch before loading content  ---  ## Authorization & Context  * The API may be called by authenticated or unauthenticated users (depending on floor visibility). * The `is_owner` field is calculated **relative to the requesting user context** (if authenticated).  ---  ## Response Format  `application/json`  ---  ## Response Structure  ### Top-Level Fields  | Field        | Type                   | Description                                                      | | ------------ | ---------------------- | ---------------------------------------------------------------- | | `floor_id`   | String                 | Public, human-readable identifier of the floor                   | | `floor_uid`  | String                 | Internal unique identifier of the floor                          | | `title`      | String                 | Display title of the floor                                       | | `details`    | String                 | Short description or summary of the floor                        | | `floor_type` | String                 | Type of floor (`PUBLIC`, `PRIVATE`, `POD`)                       | | `is_owner`   | String (`\"0\"` / `\"1\"`) | Indicates whether the requesting user is the owner               | | `blocks`     | Array                  | List of blocks available in the floor                            | | `avatar`     | Object                 | Floor logo / avatar metadata                                     | | `app_id`     | String                 | Associated application ID (used mainly for pod/developer floors) |  ---  ## Ownership Indicator  ### `is_owner`  ```json \"is_owner\": \"0\" ```  | Value | Meaning                                   | | ----- | ----------------------------------------- | | `\"1\"` | Requesting user is the owner of the floor | | `\"0\"` | Requesting user is not the owner          |  This field is typically used by clients to:  * Enable or disable edit/settings UI * Show owner-only actions  ---  ## Blocks Object  ```json \"blocks\": [   {     \"BID\": \"1765960948723\",     \"type\": \"1\",     \"title\": \"Feeds\"   } ] ```  Each block represents a **content category or service** available inside the floor.  ### Block Fields  | Field   | Type   | Description                                           | | ------- | ------ | ----------------------------------------------------- | | `BID`   | String | Unique identifier of the block                        | | `type`  | String | Block type identifier (e.g., feed, blog, forum, quiz) | | `title` | String | Display name of the block                             |  ---  ## Avatar Object  ```json \"avatar\": {   \"id\": \"1767009204367\",   \"url\": \"https://...\" } ```  | Field | Type   | Description                    | | ----- | ------ | ------------------------------ | | `id`  | String | Media identifier of the avatar | | `url` | String | CDN URL of the floor logo      |  Used to render the floor’s profile image or banner.  ---  ## Floor Type  ```json \"floor_type\": \"POD\" ```  | Value     | Meaning                               | | --------- | ------------------------------------- | | `PUBLIC`  | Open floor visible to everyone        | | `PRIVATE` | Restricted floor                      | | `POD`     | Aggregated or developer-managed floor |  `POD` floors are often associated with an `app_id` and may aggregate or serve content programmatically.  ---  ## Sample Success Response  ```json {   \"is_owner\": \"0\",   \"blocks\": [     {       \"BID\": \"1765960948723\",       \"type\": \"1\",       \"title\": \"Feeds\"     }   ],   \"floor_uid\": \"1765960956967\",   \"floor_id\": \"raghupodfloor1\",   \"details\": \"raghu\",   \"avatar\": {     \"id\": \"1767009204367\",     \"url\": \"https://d2e5822u5ecuq8.cloudfront.net/room/1765960956967/logo/1765960956967.jpg\"   },   \"title\": \"raghu\",   \"floor_type\": \"POD\",   \"app_id\": \"1765949734005\" } ```  ---  ## Notes for Developers  * This is a **lightweight metadata API** and is safe to call frequently. * Use this API **before** loading posts or analytics. * `blocks` ordering can be used directly for navigation UI. * `floor_type` + `is_owner` together determine which UI actions are allowed.  ---  ## Common Error Scenarios  ### Floor Not Found  ```json {   \"status\": \"ERROR\",   \"message\": \"Floor not found\" } ```  ### Access Restricted  ```json {   \"status\": \"ERROR\",   \"message\": \"Access denied for this floor\" } ```  ---  ### Final Mental Model  > **This API answers: “What is this floor, who owns it, and what can I do here?”**
+     * This API returns the **basic profile information of a floor**. It is used to fetch all essential metadata required to **render a floor landing page, header, or navigation context**.  The response includes:  * Floor identity and type * Ownership information relative to the requesting user * Floor metadata (title, description, avatar) * List of blocks available in the floor * App association (for pod / developer use cases)  This API does **not** return posts or content; it only provides **structural and descriptive information** about the floor.  ---  ## Typical Use Cases  * Render floor header (title, logo, description) * Decide UI permissions (owner vs non-owner) * Display available blocks (Feeds, Blog, Quiz, etc.) * Pod discovery or developer-managed floor rendering * Lightweight floor metadata fetch before loading content  ---  ## Authorization & Context  * The API may be called by authenticated or unauthenticated users (depending on floor visibility). * The `is_owner` field is calculated **relative to the requesting user context** (if authenticated).  ---  ## Response Format  `application/json`  ---  ## Response Structure  ### Top-Level Fields  | Field        | Type                   | Description                                                      | | ------------ | ---------------------- | ---------------------------------------------------------------- | | `floor_id`   | String                 | Public, human-readable identifier of the floor                   | | `floor_uid`  | String                 | Internal unique identifier of the floor                          | | `title`      | String                 | Display title of the floor                                       | | `details`    | String                 | Short description or summary of the floor                        | | `floor_type` | String                 | Type of floor (`PUBLIC`, `PRIVATE`, `POD`)                       | | `is_owner`   | String (`\"0\"` / `\"1\"`) | Indicates whether the requesting user is the owner               | | `blocks`     | Array                  | List of blocks available in the floor                            | | `avatar`     | Object                 | Floor logo / avatar metadata                                     | | `app_id`     | String                 | Associated application ID (used mainly for pod/developer floors) |  ---  ## Ownership Indicator  ### `is_owner`  ```json \"is_owner\": \"0\" ```  | Value | Meaning                                   | | ----- | ----------------------------------------- | | `\"1\"` | Requesting user is the owner of the floor | | `\"0\"` | Requesting user is not the owner          |  This field is typically used by clients to:  * Enable or disable edit/settings UI * Show owner-only actions  ---  ## Blocks Object  ```json \"blocks\": [   {     \"block_id\": \"1765960948723\",     \"type\": \"1\",     \"title\": \"Feeds\"   } ] ```  Each block represents a **content category or service** available inside the floor.  ### Block Fields  | Field   | Type   | Description                                           | | ------- | ------ | ----------------------------------------------------- | | `block_id`   | String | Unique identifier of the block                        | | `type`  | String | Block type identifier (e.g., feed, blog, forum, quiz) | | `title` | String | Display name of the block                             |  ---  ## Avatar Object  ```json \"avatar\": {   \"id\": \"1767009204367\",   \"url\": \"https://...\" } ```  | Field | Type   | Description                    | | ----- | ------ | ------------------------------ | | `id`  | String | Media identifier of the avatar | | `url` | String | CDN URL of the floor logo      |  Used to render the floor’s profile image or banner.  ---  ## Floor Type  ```json \"floor_type\": \"POD\" ```  | Value     | Meaning                               | | --------- | ------------------------------------- | | `PUBLIC`  | Open floor visible to everyone        | | `PRIVATE` | Restricted floor                      | | `POD`     | Aggregated or developer-managed floor |  `POD` floors are often associated with an `app_id` and may aggregate or serve content programmatically.  ---  ## Sample Success Response  ```json {   \"is_owner\": \"0\",   \"blocks\": [     {       \"block_id\": \"1765960948723\",       \"type\": \"1\",       \"title\": \"Feeds\"     }   ],   \"floor_uid\": \"1765960956967\",   \"floor_id\": \"raghupodfloor1\",   \"details\": \"raghu\",   \"avatar\": {     \"id\": \"1767009204367\",     \"url\": \"https://d2e5822u5ecuq8.cloudfront.net/room/1765960956967/logo/1765960956967.jpg\"   },   \"title\": \"raghu\",   \"floor_type\": \"POD\",   \"app_id\": \"1765949734005\" } ```  ---  ## Notes for Developers  * This is a **lightweight metadata API** and is safe to call frequently. * Use this API **before** loading posts or analytics. * `blocks` ordering can be used directly for navigation UI. * `floor_type` + `is_owner` together determine which UI actions are allowed.  ---  ## Common Error Scenarios  ### Floor Not Found  ```json {   \"status\": \"ERROR\",   \"message\": \"Floor not found\" } ```  ### Access Restricted  ```json {   \"status\": \"ERROR\",   \"message\": \"Access denied for this floor\" } ```  ---  ### Final Mental Model  > **This API answers: “What is this floor, who owns it, and what can I do here?”**
      * Basic information of a floor
      */
     getFloorInformationRaw(requestParameters: GetFloorInformationRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<runtime.ApiResponse<GetFloorInformation200Response>>;
     /**
-     * This API returns the **basic profile information of a floor**. It is used to fetch all essential metadata required to **render a floor landing page, header, or navigation context**.  The response includes:  * Floor identity and type * Ownership information relative to the requesting user * Floor metadata (title, description, avatar) * List of blocks available in the floor * App association (for pod / developer use cases)  This API does **not** return posts or content; it only provides **structural and descriptive information** about the floor.  ---  ## Typical Use Cases  * Render floor header (title, logo, description) * Decide UI permissions (owner vs non-owner) * Display available blocks (Feeds, Blog, Quiz, etc.) * Pod discovery or developer-managed floor rendering * Lightweight floor metadata fetch before loading content  ---  ## Authorization & Context  * The API may be called by authenticated or unauthenticated users (depending on floor visibility). * The `is_owner` field is calculated **relative to the requesting user context** (if authenticated).  ---  ## Response Format  `application/json`  ---  ## Response Structure  ### Top-Level Fields  | Field        | Type                   | Description                                                      | | ------------ | ---------------------- | ---------------------------------------------------------------- | | `floor_id`   | String                 | Public, human-readable identifier of the floor                   | | `floor_uid`  | String                 | Internal unique identifier of the floor                          | | `title`      | String                 | Display title of the floor                                       | | `details`    | String                 | Short description or summary of the floor                        | | `floor_type` | String                 | Type of floor (`PUBLIC`, `PRIVATE`, `POD`)                       | | `is_owner`   | String (`\"0\"` / `\"1\"`) | Indicates whether the requesting user is the owner               | | `blocks`     | Array                  | List of blocks available in the floor                            | | `avatar`     | Object                 | Floor logo / avatar metadata                                     | | `app_id`     | String                 | Associated application ID (used mainly for pod/developer floors) |  ---  ## Ownership Indicator  ### `is_owner`  ```json \"is_owner\": \"0\" ```  | Value | Meaning                                   | | ----- | ----------------------------------------- | | `\"1\"` | Requesting user is the owner of the floor | | `\"0\"` | Requesting user is not the owner          |  This field is typically used by clients to:  * Enable or disable edit/settings UI * Show owner-only actions  ---  ## Blocks Object  ```json \"blocks\": [   {     \"BID\": \"1765960948723\",     \"type\": \"1\",     \"title\": \"Feeds\"   } ] ```  Each block represents a **content category or service** available inside the floor.  ### Block Fields  | Field   | Type   | Description                                           | | ------- | ------ | ----------------------------------------------------- | | `BID`   | String | Unique identifier of the block                        | | `type`  | String | Block type identifier (e.g., feed, blog, forum, quiz) | | `title` | String | Display name of the block                             |  ---  ## Avatar Object  ```json \"avatar\": {   \"id\": \"1767009204367\",   \"url\": \"https://...\" } ```  | Field | Type   | Description                    | | ----- | ------ | ------------------------------ | | `id`  | String | Media identifier of the avatar | | `url` | String | CDN URL of the floor logo      |  Used to render the floor’s profile image or banner.  ---  ## Floor Type  ```json \"floor_type\": \"POD\" ```  | Value     | Meaning                               | | --------- | ------------------------------------- | | `PUBLIC`  | Open floor visible to everyone        | | `PRIVATE` | Restricted floor                      | | `POD`     | Aggregated or developer-managed floor |  `POD` floors are often associated with an `app_id` and may aggregate or serve content programmatically.  ---  ## Sample Success Response  ```json {   \"is_owner\": \"0\",   \"blocks\": [     {       \"BID\": \"1765960948723\",       \"type\": \"1\",       \"title\": \"Feeds\"     }   ],   \"floor_uid\": \"1765960956967\",   \"floor_id\": \"raghupodfloor1\",   \"details\": \"raghu\",   \"avatar\": {     \"id\": \"1767009204367\",     \"url\": \"https://d2e5822u5ecuq8.cloudfront.net/room/1765960956967/logo/1765960956967.jpg\"   },   \"title\": \"raghu\",   \"floor_type\": \"POD\",   \"app_id\": \"1765949734005\" } ```  ---  ## Notes for Developers  * This is a **lightweight metadata API** and is safe to call frequently. * Use this API **before** loading posts or analytics. * `blocks` ordering can be used directly for navigation UI. * `floor_type` + `is_owner` together determine which UI actions are allowed.  ---  ## Common Error Scenarios  ### Floor Not Found  ```json {   \"status\": \"ERROR\",   \"message\": \"Floor not found\" } ```  ### Access Restricted  ```json {   \"status\": \"ERROR\",   \"message\": \"Access denied for this floor\" } ```  ---  ### Final Mental Model  > **This API answers: “What is this floor, who owns it, and what can I do here?”**
+     * This API returns the **basic profile information of a floor**. It is used to fetch all essential metadata required to **render a floor landing page, header, or navigation context**.  The response includes:  * Floor identity and type * Ownership information relative to the requesting user * Floor metadata (title, description, avatar) * List of blocks available in the floor * App association (for pod / developer use cases)  This API does **not** return posts or content; it only provides **structural and descriptive information** about the floor.  ---  ## Typical Use Cases  * Render floor header (title, logo, description) * Decide UI permissions (owner vs non-owner) * Display available blocks (Feeds, Blog, Quiz, etc.) * Pod discovery or developer-managed floor rendering * Lightweight floor metadata fetch before loading content  ---  ## Authorization & Context  * The API may be called by authenticated or unauthenticated users (depending on floor visibility). * The `is_owner` field is calculated **relative to the requesting user context** (if authenticated).  ---  ## Response Format  `application/json`  ---  ## Response Structure  ### Top-Level Fields  | Field        | Type                   | Description                                                      | | ------------ | ---------------------- | ---------------------------------------------------------------- | | `floor_id`   | String                 | Public, human-readable identifier of the floor                   | | `floor_uid`  | String                 | Internal unique identifier of the floor                          | | `title`      | String                 | Display title of the floor                                       | | `details`    | String                 | Short description or summary of the floor                        | | `floor_type` | String                 | Type of floor (`PUBLIC`, `PRIVATE`, `POD`)                       | | `is_owner`   | String (`\"0\"` / `\"1\"`) | Indicates whether the requesting user is the owner               | | `blocks`     | Array                  | List of blocks available in the floor                            | | `avatar`     | Object                 | Floor logo / avatar metadata                                     | | `app_id`     | String                 | Associated application ID (used mainly for pod/developer floors) |  ---  ## Ownership Indicator  ### `is_owner`  ```json \"is_owner\": \"0\" ```  | Value | Meaning                                   | | ----- | ----------------------------------------- | | `\"1\"` | Requesting user is the owner of the floor | | `\"0\"` | Requesting user is not the owner          |  This field is typically used by clients to:  * Enable or disable edit/settings UI * Show owner-only actions  ---  ## Blocks Object  ```json \"blocks\": [   {     \"block_id\": \"1765960948723\",     \"type\": \"1\",     \"title\": \"Feeds\"   } ] ```  Each block represents a **content category or service** available inside the floor.  ### Block Fields  | Field   | Type   | Description                                           | | ------- | ------ | ----------------------------------------------------- | | `block_id`   | String | Unique identifier of the block                        | | `type`  | String | Block type identifier (e.g., feed, blog, forum, quiz) | | `title` | String | Display name of the block                             |  ---  ## Avatar Object  ```json \"avatar\": {   \"id\": \"1767009204367\",   \"url\": \"https://...\" } ```  | Field | Type   | Description                    | | ----- | ------ | ------------------------------ | | `id`  | String | Media identifier of the avatar | | `url` | String | CDN URL of the floor logo      |  Used to render the floor’s profile image or banner.  ---  ## Floor Type  ```json \"floor_type\": \"POD\" ```  | Value     | Meaning                               | | --------- | ------------------------------------- | | `PUBLIC`  | Open floor visible to everyone        | | `PRIVATE` | Restricted floor                      | | `POD`     | Aggregated or developer-managed floor |  `POD` floors are often associated with an `app_id` and may aggregate or serve content programmatically.  ---  ## Sample Success Response  ```json {   \"is_owner\": \"0\",   \"blocks\": [     {       \"block_id\": \"1765960948723\",       \"type\": \"1\",       \"title\": \"Feeds\"     }   ],   \"floor_uid\": \"1765960956967\",   \"floor_id\": \"raghupodfloor1\",   \"details\": \"raghu\",   \"avatar\": {     \"id\": \"1767009204367\",     \"url\": \"https://d2e5822u5ecuq8.cloudfront.net/room/1765960956967/logo/1765960956967.jpg\"   },   \"title\": \"raghu\",   \"floor_type\": \"POD\",   \"app_id\": \"1765949734005\" } ```  ---  ## Notes for Developers  * This is a **lightweight metadata API** and is safe to call frequently. * Use this API **before** loading posts or analytics. * `blocks` ordering can be used directly for navigation UI. * `floor_type` + `is_owner` together determine which UI actions are allowed.  ---  ## Common Error Scenarios  ### Floor Not Found  ```json {   \"status\": \"ERROR\",   \"message\": \"Floor not found\" } ```  ### Access Restricted  ```json {   \"status\": \"ERROR\",   \"message\": \"Access denied for this floor\" } ```  ---  ### Final Mental Model  > **This API answers: “What is this floor, who owns it, and what can I do here?”**
      * Basic information of a floor
      */
     getFloorInformation(requestParameters: GetFloorInformationRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<GetFloorInformation200Response>;

package/dist/apis/GetFloorInformationApi.js

@@ -3,7 +3,9 @@
 /* eslint-disable */
 /**
  * Floor Memory
- * The set APIs are used to develop Floor pds which can be used as their personal assistants.   This set of APIs are divided into two parts.  - Memory and  - Registration.   The developer has two ways of using the APIs for the app development. Developer can choose to the  Registration APIs for using the existing xfloor infracture or can implement custom Registration process. In the case of custom registration process, the developer is bound to provide proper authentication mechanisms and then send the user information to xlfoor.
+ * The set APIs are used to develop Floor pds which can be used as their personal assistants. This set of APIs are divided into two parts.
+ * - Memory and
+ * - Registration. The developer has two ways of using the APIs for the app development. Developer can choose to the Registration APIs for using the existing xfloor infracture or can implement custom Registration process. In the case of custom registration process, the developer is bound to provide proper authentication mechanisms and then send the user information to xlfoor.
  *
  * The version of the OpenAPI document: 1.0.0
  * Contact: contact@ipomo.in
@@ -76,7 +78,7 @@ var GetFloorInformationApi = /** @class */ (function (_super) {
         return _super !== null && _super.apply(this, arguments) || this;
     }
     /**
-     * This API returns the **basic profile information of a floor**. It is used to fetch all essential metadata required to **render a floor landing page, header, or navigation context**.  The response includes:  * Floor identity and type * Ownership information relative to the requesting user * Floor metadata (title, description, avatar) * List of blocks available in the floor * App association (for pod / developer use cases)  This API does **not** return posts or content; it only provides **structural and descriptive information** about the floor.  ---  ## Typical Use Cases  * Render floor header (title, logo, description) * Decide UI permissions (owner vs non-owner) * Display available blocks (Feeds, Blog, Quiz, etc.) * Pod discovery or developer-managed floor rendering * Lightweight floor metadata fetch before loading content  ---  ## Authorization & Context  * The API may be called by authenticated or unauthenticated users (depending on floor visibility). * The `is_owner` field is calculated **relative to the requesting user context** (if authenticated).  ---  ## Response Format  `application/json`  ---  ## Response Structure  ### Top-Level Fields  | Field        | Type                   | Description                                                      | | ------------ | ---------------------- | ---------------------------------------------------------------- | | `floor_id`   | String                 | Public, human-readable identifier of the floor                   | | `floor_uid`  | String                 | Internal unique identifier of the floor                          | | `title`      | String                 | Display title of the floor                                       | | `details`    | String                 | Short description or summary of the floor                        | | `floor_type` | String                 | Type of floor (`PUBLIC`, `PRIVATE`, `POD`)                       | | `is_owner`   | String (`\"0\"` / `\"1\"`) | Indicates whether the requesting user is the owner               | | `blocks`     | Array                  | List of blocks available in the floor                            | | `avatar`     | Object                 | Floor logo / avatar metadata                                     | | `app_id`     | String                 | Associated application ID (used mainly for pod/developer floors) |  ---  ## Ownership Indicator  ### `is_owner`  ```json \"is_owner\": \"0\" ```  | Value | Meaning                                   | | ----- | ----------------------------------------- | | `\"1\"` | Requesting user is the owner of the floor | | `\"0\"` | Requesting user is not the owner          |  This field is typically used by clients to:  * Enable or disable edit/settings UI * Show owner-only actions  ---  ## Blocks Object  ```json \"blocks\": [   {     \"BID\": \"1765960948723\",     \"type\": \"1\",     \"title\": \"Feeds\"   } ] ```  Each block represents a **content category or service** available inside the floor.  ### Block Fields  | Field   | Type   | Description                                           | | ------- | ------ | ----------------------------------------------------- | | `BID`   | String | Unique identifier of the block                        | | `type`  | String | Block type identifier (e.g., feed, blog, forum, quiz) | | `title` | String | Display name of the block                             |  ---  ## Avatar Object  ```json \"avatar\": {   \"id\": \"1767009204367\",   \"url\": \"https://...\" } ```  | Field | Type   | Description                    | | ----- | ------ | ------------------------------ | | `id`  | String | Media identifier of the avatar | | `url` | String | CDN URL of the floor logo      |  Used to render the floor’s profile image or banner.  ---  ## Floor Type  ```json \"floor_type\": \"POD\" ```  | Value     | Meaning                               | | --------- | ------------------------------------- | | `PUBLIC`  | Open floor visible to everyone        | | `PRIVATE` | Restricted floor                      | | `POD`     | Aggregated or developer-managed floor |  `POD` floors are often associated with an `app_id` and may aggregate or serve content programmatically.  ---  ## Sample Success Response  ```json {   \"is_owner\": \"0\",   \"blocks\": [     {       \"BID\": \"1765960948723\",       \"type\": \"1\",       \"title\": \"Feeds\"     }   ],   \"floor_uid\": \"1765960956967\",   \"floor_id\": \"raghupodfloor1\",   \"details\": \"raghu\",   \"avatar\": {     \"id\": \"1767009204367\",     \"url\": \"https://d2e5822u5ecuq8.cloudfront.net/room/1765960956967/logo/1765960956967.jpg\"   },   \"title\": \"raghu\",   \"floor_type\": \"POD\",   \"app_id\": \"1765949734005\" } ```  ---  ## Notes for Developers  * This is a **lightweight metadata API** and is safe to call frequently. * Use this API **before** loading posts or analytics. * `blocks` ordering can be used directly for navigation UI. * `floor_type` + `is_owner` together determine which UI actions are allowed.  ---  ## Common Error Scenarios  ### Floor Not Found  ```json {   \"status\": \"ERROR\",   \"message\": \"Floor not found\" } ```  ### Access Restricted  ```json {   \"status\": \"ERROR\",   \"message\": \"Access denied for this floor\" } ```  ---  ### Final Mental Model  > **This API answers: “What is this floor, who owns it, and what can I do here?”**
+     * This API returns the **basic profile information of a floor**. It is used to fetch all essential metadata required to **render a floor landing page, header, or navigation context**.  The response includes:  * Floor identity and type * Ownership information relative to the requesting user * Floor metadata (title, description, avatar) * List of blocks available in the floor * App association (for pod / developer use cases)  This API does **not** return posts or content; it only provides **structural and descriptive information** about the floor.  ---  ## Typical Use Cases  * Render floor header (title, logo, description) * Decide UI permissions (owner vs non-owner) * Display available blocks (Feeds, Blog, Quiz, etc.) * Pod discovery or developer-managed floor rendering * Lightweight floor metadata fetch before loading content  ---  ## Authorization & Context  * The API may be called by authenticated or unauthenticated users (depending on floor visibility). * The `is_owner` field is calculated **relative to the requesting user context** (if authenticated).  ---  ## Response Format  `application/json`  ---  ## Response Structure  ### Top-Level Fields  | Field        | Type                   | Description                                                      | | ------------ | ---------------------- | ---------------------------------------------------------------- | | `floor_id`   | String                 | Public, human-readable identifier of the floor                   | | `floor_uid`  | String                 | Internal unique identifier of the floor                          | | `title`      | String                 | Display title of the floor                                       | | `details`    | String                 | Short description or summary of the floor                        | | `floor_type` | String                 | Type of floor (`PUBLIC`, `PRIVATE`, `POD`)                       | | `is_owner`   | String (`\"0\"` / `\"1\"`) | Indicates whether the requesting user is the owner               | | `blocks`     | Array                  | List of blocks available in the floor                            | | `avatar`     | Object                 | Floor logo / avatar metadata                                     | | `app_id`     | String                 | Associated application ID (used mainly for pod/developer floors) |  ---  ## Ownership Indicator  ### `is_owner`  ```json \"is_owner\": \"0\" ```  | Value | Meaning                                   | | ----- | ----------------------------------------- | | `\"1\"` | Requesting user is the owner of the floor | | `\"0\"` | Requesting user is not the owner          |  This field is typically used by clients to:  * Enable or disable edit/settings UI * Show owner-only actions  ---  ## Blocks Object  ```json \"blocks\": [   {     \"block_id\": \"1765960948723\",     \"type\": \"1\",     \"title\": \"Feeds\"   } ] ```  Each block represents a **content category or service** available inside the floor.  ### Block Fields  | Field   | Type   | Description                                           | | ------- | ------ | ----------------------------------------------------- | | `block_id`   | String | Unique identifier of the block                        | | `type`  | String | Block type identifier (e.g., feed, blog, forum, quiz) | | `title` | String | Display name of the block                             |  ---  ## Avatar Object  ```json \"avatar\": {   \"id\": \"1767009204367\",   \"url\": \"https://...\" } ```  | Field | Type   | Description                    | | ----- | ------ | ------------------------------ | | `id`  | String | Media identifier of the avatar | | `url` | String | CDN URL of the floor logo      |  Used to render the floor’s profile image or banner.  ---  ## Floor Type  ```json \"floor_type\": \"POD\" ```  | Value     | Meaning                               | | --------- | ------------------------------------- | | `PUBLIC`  | Open floor visible to everyone        | | `PRIVATE` | Restricted floor                      | | `POD`     | Aggregated or developer-managed floor |  `POD` floors are often associated with an `app_id` and may aggregate or serve content programmatically.  ---  ## Sample Success Response  ```json {   \"is_owner\": \"0\",   \"blocks\": [     {       \"block_id\": \"1765960948723\",       \"type\": \"1\",       \"title\": \"Feeds\"     }   ],   \"floor_uid\": \"1765960956967\",   \"floor_id\": \"raghupodfloor1\",   \"details\": \"raghu\",   \"avatar\": {     \"id\": \"1767009204367\",     \"url\": \"https://d2e5822u5ecuq8.cloudfront.net/room/1765960956967/logo/1765960956967.jpg\"   },   \"title\": \"raghu\",   \"floor_type\": \"POD\",   \"app_id\": \"1765949734005\" } ```  ---  ## Notes for Developers  * This is a **lightweight metadata API** and is safe to call frequently. * Use this API **before** loading posts or analytics. * `blocks` ordering can be used directly for navigation UI. * `floor_type` + `is_owner` together determine which UI actions are allowed.  ---  ## Common Error Scenarios  ### Floor Not Found  ```json {   \"status\": \"ERROR\",   \"message\": \"Floor not found\" } ```  ### Access Restricted  ```json {   \"status\": \"ERROR\",   \"message\": \"Access denied for this floor\" } ```  ---  ### Final Mental Model  > **This API answers: “What is this floor, who owns it, and what can I do here?”**
      * Basic information of a floor
      */
     GetFloorInformationApi.prototype.getFloorInformationRaw = function (requestParameters, initOverrides) {
@@ -122,7 +124,7 @@ var GetFloorInformationApi = /** @class */ (function (_super) {
         });
     };
     /**
-     * This API returns the **basic profile information of a floor**. It is used to fetch all essential metadata required to **render a floor landing page, header, or navigation context**.  The response includes:  * Floor identity and type * Ownership information relative to the requesting user * Floor metadata (title, description, avatar) * List of blocks available in the floor * App association (for pod / developer use cases)  This API does **not** return posts or content; it only provides **structural and descriptive information** about the floor.  ---  ## Typical Use Cases  * Render floor header (title, logo, description) * Decide UI permissions (owner vs non-owner) * Display available blocks (Feeds, Blog, Quiz, etc.) * Pod discovery or developer-managed floor rendering * Lightweight floor metadata fetch before loading content  ---  ## Authorization & Context  * The API may be called by authenticated or unauthenticated users (depending on floor visibility). * The `is_owner` field is calculated **relative to the requesting user context** (if authenticated).  ---  ## Response Format  `application/json`  ---  ## Response Structure  ### Top-Level Fields  | Field        | Type                   | Description                                                      | | ------------ | ---------------------- | ---------------------------------------------------------------- | | `floor_id`   | String                 | Public, human-readable identifier of the floor                   | | `floor_uid`  | String                 | Internal unique identifier of the floor                          | | `title`      | String                 | Display title of the floor                                       | | `details`    | String                 | Short description or summary of the floor                        | | `floor_type` | String                 | Type of floor (`PUBLIC`, `PRIVATE`, `POD`)                       | | `is_owner`   | String (`\"0\"` / `\"1\"`) | Indicates whether the requesting user is the owner               | | `blocks`     | Array                  | List of blocks available in the floor                            | | `avatar`     | Object                 | Floor logo / avatar metadata                                     | | `app_id`     | String                 | Associated application ID (used mainly for pod/developer floors) |  ---  ## Ownership Indicator  ### `is_owner`  ```json \"is_owner\": \"0\" ```  | Value | Meaning                                   | | ----- | ----------------------------------------- | | `\"1\"` | Requesting user is the owner of the floor | | `\"0\"` | Requesting user is not the owner          |  This field is typically used by clients to:  * Enable or disable edit/settings UI * Show owner-only actions  ---  ## Blocks Object  ```json \"blocks\": [   {     \"BID\": \"1765960948723\",     \"type\": \"1\",     \"title\": \"Feeds\"   } ] ```  Each block represents a **content category or service** available inside the floor.  ### Block Fields  | Field   | Type   | Description                                           | | ------- | ------ | ----------------------------------------------------- | | `BID`   | String | Unique identifier of the block                        | | `type`  | String | Block type identifier (e.g., feed, blog, forum, quiz) | | `title` | String | Display name of the block                             |  ---  ## Avatar Object  ```json \"avatar\": {   \"id\": \"1767009204367\",   \"url\": \"https://...\" } ```  | Field | Type   | Description                    | | ----- | ------ | ------------------------------ | | `id`  | String | Media identifier of the avatar | | `url` | String | CDN URL of the floor logo      |  Used to render the floor’s profile image or banner.  ---  ## Floor Type  ```json \"floor_type\": \"POD\" ```  | Value     | Meaning                               | | --------- | ------------------------------------- | | `PUBLIC`  | Open floor visible to everyone        | | `PRIVATE` | Restricted floor                      | | `POD`     | Aggregated or developer-managed floor |  `POD` floors are often associated with an `app_id` and may aggregate or serve content programmatically.  ---  ## Sample Success Response  ```json {   \"is_owner\": \"0\",   \"blocks\": [     {       \"BID\": \"1765960948723\",       \"type\": \"1\",       \"title\": \"Feeds\"     }   ],   \"floor_uid\": \"1765960956967\",   \"floor_id\": \"raghupodfloor1\",   \"details\": \"raghu\",   \"avatar\": {     \"id\": \"1767009204367\",     \"url\": \"https://d2e5822u5ecuq8.cloudfront.net/room/1765960956967/logo/1765960956967.jpg\"   },   \"title\": \"raghu\",   \"floor_type\": \"POD\",   \"app_id\": \"1765949734005\" } ```  ---  ## Notes for Developers  * This is a **lightweight metadata API** and is safe to call frequently. * Use this API **before** loading posts or analytics. * `blocks` ordering can be used directly for navigation UI. * `floor_type` + `is_owner` together determine which UI actions are allowed.  ---  ## Common Error Scenarios  ### Floor Not Found  ```json {   \"status\": \"ERROR\",   \"message\": \"Floor not found\" } ```  ### Access Restricted  ```json {   \"status\": \"ERROR\",   \"message\": \"Access denied for this floor\" } ```  ---  ### Final Mental Model  > **This API answers: “What is this floor, who owns it, and what can I do here?”**
+     * This API returns the **basic profile information of a floor**. It is used to fetch all essential metadata required to **render a floor landing page, header, or navigation context**.  The response includes:  * Floor identity and type * Ownership information relative to the requesting user * Floor metadata (title, description, avatar) * List of blocks available in the floor * App association (for pod / developer use cases)  This API does **not** return posts or content; it only provides **structural and descriptive information** about the floor.  ---  ## Typical Use Cases  * Render floor header (title, logo, description) * Decide UI permissions (owner vs non-owner) * Display available blocks (Feeds, Blog, Quiz, etc.) * Pod discovery or developer-managed floor rendering * Lightweight floor metadata fetch before loading content  ---  ## Authorization & Context  * The API may be called by authenticated or unauthenticated users (depending on floor visibility). * The `is_owner` field is calculated **relative to the requesting user context** (if authenticated).  ---  ## Response Format  `application/json`  ---  ## Response Structure  ### Top-Level Fields  | Field        | Type                   | Description                                                      | | ------------ | ---------------------- | ---------------------------------------------------------------- | | `floor_id`   | String                 | Public, human-readable identifier of the floor                   | | `floor_uid`  | String                 | Internal unique identifier of the floor                          | | `title`      | String                 | Display title of the floor                                       | | `details`    | String                 | Short description or summary of the floor                        | | `floor_type` | String                 | Type of floor (`PUBLIC`, `PRIVATE`, `POD`)                       | | `is_owner`   | String (`\"0\"` / `\"1\"`) | Indicates whether the requesting user is the owner               | | `blocks`     | Array                  | List of blocks available in the floor                            | | `avatar`     | Object                 | Floor logo / avatar metadata                                     | | `app_id`     | String                 | Associated application ID (used mainly for pod/developer floors) |  ---  ## Ownership Indicator  ### `is_owner`  ```json \"is_owner\": \"0\" ```  | Value | Meaning                                   | | ----- | ----------------------------------------- | | `\"1\"` | Requesting user is the owner of the floor | | `\"0\"` | Requesting user is not the owner          |  This field is typically used by clients to:  * Enable or disable edit/settings UI * Show owner-only actions  ---  ## Blocks Object  ```json \"blocks\": [   {     \"block_id\": \"1765960948723\",     \"type\": \"1\",     \"title\": \"Feeds\"   } ] ```  Each block represents a **content category or service** available inside the floor.  ### Block Fields  | Field   | Type   | Description                                           | | ------- | ------ | ----------------------------------------------------- | | `block_id`   | String | Unique identifier of the block                        | | `type`  | String | Block type identifier (e.g., feed, blog, forum, quiz) | | `title` | String | Display name of the block                             |  ---  ## Avatar Object  ```json \"avatar\": {   \"id\": \"1767009204367\",   \"url\": \"https://...\" } ```  | Field | Type   | Description                    | | ----- | ------ | ------------------------------ | | `id`  | String | Media identifier of the avatar | | `url` | String | CDN URL of the floor logo      |  Used to render the floor’s profile image or banner.  ---  ## Floor Type  ```json \"floor_type\": \"POD\" ```  | Value     | Meaning                               | | --------- | ------------------------------------- | | `PUBLIC`  | Open floor visible to everyone        | | `PRIVATE` | Restricted floor                      | | `POD`     | Aggregated or developer-managed floor |  `POD` floors are often associated with an `app_id` and may aggregate or serve content programmatically.  ---  ## Sample Success Response  ```json {   \"is_owner\": \"0\",   \"blocks\": [     {       \"block_id\": \"1765960948723\",       \"type\": \"1\",       \"title\": \"Feeds\"     }   ],   \"floor_uid\": \"1765960956967\",   \"floor_id\": \"raghupodfloor1\",   \"details\": \"raghu\",   \"avatar\": {     \"id\": \"1767009204367\",     \"url\": \"https://d2e5822u5ecuq8.cloudfront.net/room/1765960956967/logo/1765960956967.jpg\"   },   \"title\": \"raghu\",   \"floor_type\": \"POD\",   \"app_id\": \"1765949734005\" } ```  ---  ## Notes for Developers  * This is a **lightweight metadata API** and is safe to call frequently. * Use this API **before** loading posts or analytics. * `blocks` ordering can be used directly for navigation UI. * `floor_type` + `is_owner` together determine which UI actions are allowed.  ---  ## Common Error Scenarios  ### Floor Not Found  ```json {   \"status\": \"ERROR\",   \"message\": \"Floor not found\" } ```  ### Access Restricted  ```json {   \"status\": \"ERROR\",   \"message\": \"Access denied for this floor\" } ```  ---  ### Final Mental Model  > **This API answers: “What is this floor, who owns it, and what can I do here?”**
      * Basic information of a floor
      */
     GetFloorInformationApi.prototype.getFloorInformation = function (requestParameters, initOverrides) {

package/dist/apis/GetRecentEventsApi.d.ts

@@ -1,6 +1,8 @@
 /**
  * Floor Memory
- * The set APIs are used to develop Floor pds which can be used as their personal assistants.   This set of APIs are divided into two parts.  - Memory and  - Registration.   The developer has two ways of using the APIs for the app development. Developer can choose to the  Registration APIs for using the existing xfloor infracture or can implement custom Registration process. In the case of custom registration process, the developer is bound to provide proper authentication mechanisms and then send the user information to xlfoor.
+ * The set APIs are used to develop Floor pds which can be used as their personal assistants. This set of APIs are divided into two parts.
+ * - Memory and
+ * - Registration. The developer has two ways of using the APIs for the app development. Developer can choose to the Registration APIs for using the existing xfloor infracture or can implement custom Registration process. In the case of custom registration process, the developer is bound to provide proper authentication mechanisms and then send the user information to xlfoor.
  *
  * The version of the OpenAPI document: 1.0.0
  * Contact: contact@ipomo.in

package/dist/apis/GetRecentEventsApi.js

@@ -3,7 +3,9 @@
 /* eslint-disable */
 /**
  * Floor Memory
- * The set APIs are used to develop Floor pds which can be used as their personal assistants.   This set of APIs are divided into two parts.  - Memory and  - Registration.   The developer has two ways of using the APIs for the app development. Developer can choose to the  Registration APIs for using the existing xfloor infracture or can implement custom Registration process. In the case of custom registration process, the developer is bound to provide proper authentication mechanisms and then send the user information to xlfoor.
+ * The set APIs are used to develop Floor pds which can be used as their personal assistants. This set of APIs are divided into two parts.
+ * - Memory and
+ * - Registration. The developer has two ways of using the APIs for the app development. Developer can choose to the Registration APIs for using the existing xfloor infracture or can implement custom Registration process. In the case of custom registration process, the developer is bound to provide proper authentication mechanisms and then send the user information to xlfoor.
  *
  * The version of the OpenAPI document: 1.0.0
  * Contact: contact@ipomo.in

package/dist/apis/QueryApi.d.ts

@@ -1,6 +1,8 @@
 /**
  * Floor Memory
- * The set APIs are used to develop Floor pds which can be used as their personal assistants.   This set of APIs are divided into two parts.  - Memory and  - Registration.   The developer has two ways of using the APIs for the app development. Developer can choose to the  Registration APIs for using the existing xfloor infracture or can implement custom Registration process. In the case of custom registration process, the developer is bound to provide proper authentication mechanisms and then send the user information to xlfoor.
+ * The set APIs are used to develop Floor pds which can be used as their personal assistants. This set of APIs are divided into two parts.
+ * - Memory and
+ * - Registration. The developer has two ways of using the APIs for the app development. Developer can choose to the Registration APIs for using the existing xfloor infracture or can implement custom Registration process. In the case of custom registration process, the developer is bound to provide proper authentication mechanisms and then send the user information to xlfoor.
  *
  * The version of the OpenAPI document: 1.0.0
  * Contact: contact@ipomo.in

package/dist/apis/QueryApi.js

@@ -3,7 +3,9 @@
 /* eslint-disable */
 /**
  * Floor Memory
- * The set APIs are used to develop Floor pds which can be used as their personal assistants.   This set of APIs are divided into two parts.  - Memory and  - Registration.   The developer has two ways of using the APIs for the app development. Developer can choose to the  Registration APIs for using the existing xfloor infracture or can implement custom Registration process. In the case of custom registration process, the developer is bound to provide proper authentication mechanisms and then send the user information to xlfoor.
+ * The set APIs are used to develop Floor pds which can be used as their personal assistants. This set of APIs are divided into two parts.
+ * - Memory and
+ * - Registration. The developer has two ways of using the APIs for the app development. Developer can choose to the Registration APIs for using the existing xfloor infracture or can implement custom Registration process. In the case of custom registration process, the developer is bound to provide proper authentication mechanisms and then send the user information to xlfoor.
  *
  * The version of the OpenAPI document: 1.0.0
  * Contact: contact@ipomo.in

package/dist/models/BlockDetails.d.ts

@@ -1,6 +1,8 @@
 /**
  * Floor Memory
- * The set APIs are used to develop Floor pds which can be used as their personal assistants.   This set of APIs are divided into two parts.  - Memory and  - Registration.   The developer has two ways of using the APIs for the app development. Developer can choose to the  Registration APIs for using the existing xfloor infracture or can implement custom Registration process. In the case of custom registration process, the developer is bound to provide proper authentication mechanisms and then send the user information to xlfoor.
+ * The set APIs are used to develop Floor pds which can be used as their personal assistants. This set of APIs are divided into two parts.
+ * - Memory and
+ * - Registration. The developer has two ways of using the APIs for the app development. Developer can choose to the Registration APIs for using the existing xfloor infracture or can implement custom Registration process. In the case of custom registration process, the developer is bound to provide proper authentication mechanisms and then send the user information to xlfoor.
  *
  * The version of the OpenAPI document: 1.0.0
  * Contact: contact@ipomo.in
@@ -20,7 +22,7 @@ export interface BlockDetails {
      * @type {string}
      * @memberof BlockDetails
      */
-    bid: string;
+    blockId: string;
     /**
      * Block Type
      * @type {string}

package/dist/models/BlockDetails.js

@@ -3,7 +3,9 @@
 /* eslint-disable */
 /**
  * Floor Memory
- * The set APIs are used to develop Floor pds which can be used as their personal assistants.   This set of APIs are divided into two parts.  - Memory and  - Registration.   The developer has two ways of using the APIs for the app development. Developer can choose to the  Registration APIs for using the existing xfloor infracture or can implement custom Registration process. In the case of custom registration process, the developer is bound to provide proper authentication mechanisms and then send the user information to xlfoor.
+ * The set APIs are used to develop Floor pds which can be used as their personal assistants. This set of APIs are divided into two parts.
+ * - Memory and
+ * - Registration. The developer has two ways of using the APIs for the app development. Developer can choose to the Registration APIs for using the existing xfloor infracture or can implement custom Registration process. In the case of custom registration process, the developer is bound to provide proper authentication mechanisms and then send the user information to xlfoor.
  *
  * The version of the OpenAPI document: 1.0.0
  * Contact: contact@ipomo.in
@@ -22,7 +24,7 @@ exports.BlockDetailsToJSONTyped = BlockDetailsToJSONTyped;
  * Check if a given object implements the BlockDetails interface.
  */
 function instanceOfBlockDetails(value) {
-    if (!('bid' in value) || value['bid'] === undefined)
+    if (!('blockId' in value) || value['blockId'] === undefined)
         return false;
     if (!('type' in value) || value['type'] === undefined)
         return false;
@@ -38,7 +40,7 @@ function BlockDetailsFromJSONTyped(json, ignoreDiscriminator) {
         return json;
     }
     return {
-        'bid': json['bid'],
+        'blockId': json['block_id'],
         'type': json['type'],
         'title': json['title'],
     };
@@ -52,7 +54,7 @@ function BlockDetailsToJSONTyped(value, ignoreDiscriminator) {
         return value;
     }
     return {
-        'bid': value['bid'],
+        'block_id': value['blockId'],
         'type': value['type'],
         'title': value['title'],
     };

package/dist/models/ChangePassword200Response.d.ts

@@ -1,6 +1,8 @@
 /**
  * Floor Memory
- * The set APIs are used to develop Floor pds which can be used as their personal assistants.   This set of APIs are divided into two parts.  - Memory and  - Registration.   The developer has two ways of using the APIs for the app development. Developer can choose to the  Registration APIs for using the existing xfloor infracture or can implement custom Registration process. In the case of custom registration process, the developer is bound to provide proper authentication mechanisms and then send the user information to xlfoor.
+ * The set APIs are used to develop Floor pds which can be used as their personal assistants. This set of APIs are divided into two parts.
+ * - Memory and
+ * - Registration. The developer has two ways of using the APIs for the app development. Developer can choose to the Registration APIs for using the existing xfloor infracture or can implement custom Registration process. In the case of custom registration process, the developer is bound to provide proper authentication mechanisms and then send the user information to xlfoor.
  *
  * The version of the OpenAPI document: 1.0.0
  * Contact: contact@ipomo.in

package/dist/models/ChangePassword200Response.js

@@ -3,7 +3,9 @@
 /* eslint-disable */
 /**
  * Floor Memory
- * The set APIs are used to develop Floor pds which can be used as their personal assistants.   This set of APIs are divided into two parts.  - Memory and  - Registration.   The developer has two ways of using the APIs for the app development. Developer can choose to the  Registration APIs for using the existing xfloor infracture or can implement custom Registration process. In the case of custom registration process, the developer is bound to provide proper authentication mechanisms and then send the user information to xlfoor.
+ * The set APIs are used to develop Floor pds which can be used as their personal assistants. This set of APIs are divided into two parts.
+ * - Memory and
+ * - Registration. The developer has two ways of using the APIs for the app development. Developer can choose to the Registration APIs for using the existing xfloor infracture or can implement custom Registration process. In the case of custom registration process, the developer is bound to provide proper authentication mechanisms and then send the user information to xlfoor.
  *
  * The version of the OpenAPI document: 1.0.0
  * Contact: contact@ipomo.in

package/dist/models/ConversationThreads200Response.d.ts

@@ -0,0 +1,41 @@
+/**
+ * Floor Memory
+ * The set APIs are used to develop Floor pds which can be used as their personal assistants. This set of APIs are divided into two parts.
+ * - Memory and
+ * - Registration. The developer has two ways of using the APIs for the app development. Developer can choose to the Registration APIs for using the existing xfloor infracture or can implement custom Registration process. In the case of custom registration process, the developer is bound to provide proper authentication mechanisms and then send the user information to xlfoor.
+ *
+ * The version of the OpenAPI document: 1.0.0
+ * Contact: contact@ipomo.in
+ *
+ * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
+ * https://openapi-generator.tech
+ * Do not edit the class manually.
+ */
+import type { ConversationThreads200ResponseThreadsInner } from './ConversationThreads200ResponseThreadsInner';
+/**
+ *
+ * @export
+ * @interface ConversationThreads200Response
+ */
+export interface ConversationThreads200Response {
+    /**
+     *
+     * @type {string}
+     * @memberof ConversationThreads200Response
+     */
+    userId: string;
+    /**
+     *
+     * @type {Array<ConversationThreads200ResponseThreadsInner>}
+     * @memberof ConversationThreads200Response
+     */
+    threads: Array<ConversationThreads200ResponseThreadsInner>;
+}
+/**
+ * Check if a given object implements the ConversationThreads200Response interface.
+ */
+export declare function instanceOfConversationThreads200Response(value: object): value is ConversationThreads200Response;
+export declare function ConversationThreads200ResponseFromJSON(json: any): ConversationThreads200Response;
+export declare function ConversationThreads200ResponseFromJSONTyped(json: any, ignoreDiscriminator: boolean): ConversationThreads200Response;
+export declare function ConversationThreads200ResponseToJSON(json: any): ConversationThreads200Response;
+export declare function ConversationThreads200ResponseToJSONTyped(value?: ConversationThreads200Response | null, ignoreDiscriminator?: boolean): any;

package/dist/models/ConversationThreads200Response.js

@@ -0,0 +1,58 @@
+"use strict";
+/* tslint:disable */
+/* eslint-disable */
+/**
+ * Floor Memory
+ * The set APIs are used to develop Floor pds which can be used as their personal assistants. This set of APIs are divided into two parts.
+ * - Memory and
+ * - Registration. The developer has two ways of using the APIs for the app development. Developer can choose to the Registration APIs for using the existing xfloor infracture or can implement custom Registration process. In the case of custom registration process, the developer is bound to provide proper authentication mechanisms and then send the user information to xlfoor.
+ *
+ * The version of the OpenAPI document: 1.0.0
+ * Contact: contact@ipomo.in
+ *
+ * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
+ * https://openapi-generator.tech
+ * Do not edit the class manually.
+ */
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.instanceOfConversationThreads200Response = instanceOfConversationThreads200Response;
+exports.ConversationThreads200ResponseFromJSON = ConversationThreads200ResponseFromJSON;
+exports.ConversationThreads200ResponseFromJSONTyped = ConversationThreads200ResponseFromJSONTyped;
+exports.ConversationThreads200ResponseToJSON = ConversationThreads200ResponseToJSON;
+exports.ConversationThreads200ResponseToJSONTyped = ConversationThreads200ResponseToJSONTyped;
+var ConversationThreads200ResponseThreadsInner_1 = require("./ConversationThreads200ResponseThreadsInner");
+/**
+ * Check if a given object implements the ConversationThreads200Response interface.
+ */
+function instanceOfConversationThreads200Response(value) {
+    if (!('userId' in value) || value['userId'] === undefined)
+        return false;
+    if (!('threads' in value) || value['threads'] === undefined)
+        return false;
+    return true;
+}
+function ConversationThreads200ResponseFromJSON(json) {
+    return ConversationThreads200ResponseFromJSONTyped(json, false);
+}
+function ConversationThreads200ResponseFromJSONTyped(json, ignoreDiscriminator) {
+    if (json == null) {
+        return json;
+    }
+    return {
+        'userId': json['user_id'],
+        'threads': (json['threads'].map(ConversationThreads200ResponseThreadsInner_1.ConversationThreads200ResponseThreadsInnerFromJSON)),
+    };
+}
+function ConversationThreads200ResponseToJSON(json) {
+    return ConversationThreads200ResponseToJSONTyped(json, false);
+}
+function ConversationThreads200ResponseToJSONTyped(value, ignoreDiscriminator) {
+    if (ignoreDiscriminator === void 0) { ignoreDiscriminator = false; }
+    if (value == null) {
+        return value;
+    }
+    return {
+        'user_id': value['userId'],
+        'threads': (value['threads'].map(ConversationThreads200ResponseThreadsInner_1.ConversationThreads200ResponseThreadsInnerToJSON)),
+    };
+}

package/dist/models/ConversationThreads200ResponseThreadsInner.d.ts

@@ -0,0 +1,46 @@
+/**
+ * Floor Memory
+ * The set APIs are used to develop Floor pds which can be used as their personal assistants. This set of APIs are divided into two parts.
+ * - Memory and
+ * - Registration. The developer has two ways of using the APIs for the app development. Developer can choose to the Registration APIs for using the existing xfloor infracture or can implement custom Registration process. In the case of custom registration process, the developer is bound to provide proper authentication mechanisms and then send the user information to xlfoor.
+ *
+ * The version of the OpenAPI document: 1.0.0
+ * Contact: contact@ipomo.in
+ *
+ * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
+ * https://openapi-generator.tech
+ * Do not edit the class manually.
+ */
+/**
+ *
+ * @export
+ * @interface ConversationThreads200ResponseThreadsInner
+ */
+export interface ConversationThreads200ResponseThreadsInner {
+    /**
+     *
+     * @type {string}
+     * @memberof ConversationThreads200ResponseThreadsInner
+     */
+    threadId: string;
+    /**
+     *
+     * @type {string}
+     * @memberof ConversationThreads200ResponseThreadsInner
+     */
+    title: string;
+    /**
+     *
+     * @type {string}
+     * @memberof ConversationThreads200ResponseThreadsInner
+     */
+    lastUpdated: string;
+}
+/**
+ * Check if a given object implements the ConversationThreads200ResponseThreadsInner interface.
+ */
+export declare function instanceOfConversationThreads200ResponseThreadsInner(value: object): value is ConversationThreads200ResponseThreadsInner;
+export declare function ConversationThreads200ResponseThreadsInnerFromJSON(json: any): ConversationThreads200ResponseThreadsInner;
+export declare function ConversationThreads200ResponseThreadsInnerFromJSONTyped(json: any, ignoreDiscriminator: boolean): ConversationThreads200ResponseThreadsInner;
+export declare function ConversationThreads200ResponseThreadsInnerToJSON(json: any): ConversationThreads200ResponseThreadsInner;
+export declare function ConversationThreads200ResponseThreadsInnerToJSONTyped(value?: ConversationThreads200ResponseThreadsInner | null, ignoreDiscriminator?: boolean): any;

package/dist/models/ConversationThreads200ResponseThreadsInner.js

@@ -0,0 +1,61 @@
+"use strict";
+/* tslint:disable */
+/* eslint-disable */
+/**
+ * Floor Memory
+ * The set APIs are used to develop Floor pds which can be used as their personal assistants. This set of APIs are divided into two parts.
+ * - Memory and
+ * - Registration. The developer has two ways of using the APIs for the app development. Developer can choose to the Registration APIs for using the existing xfloor infracture or can implement custom Registration process. In the case of custom registration process, the developer is bound to provide proper authentication mechanisms and then send the user information to xlfoor.
+ *
+ * The version of the OpenAPI document: 1.0.0
+ * Contact: contact@ipomo.in
+ *
+ * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
+ * https://openapi-generator.tech
+ * Do not edit the class manually.
+ */
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.instanceOfConversationThreads200ResponseThreadsInner = instanceOfConversationThreads200ResponseThreadsInner;
+exports.ConversationThreads200ResponseThreadsInnerFromJSON = ConversationThreads200ResponseThreadsInnerFromJSON;
+exports.ConversationThreads200ResponseThreadsInnerFromJSONTyped = ConversationThreads200ResponseThreadsInnerFromJSONTyped;
+exports.ConversationThreads200ResponseThreadsInnerToJSON = ConversationThreads200ResponseThreadsInnerToJSON;
+exports.ConversationThreads200ResponseThreadsInnerToJSONTyped = ConversationThreads200ResponseThreadsInnerToJSONTyped;
+/**
+ * Check if a given object implements the ConversationThreads200ResponseThreadsInner interface.
+ */
+function instanceOfConversationThreads200ResponseThreadsInner(value) {
+    if (!('threadId' in value) || value['threadId'] === undefined)
+        return false;
+    if (!('title' in value) || value['title'] === undefined)
+        return false;
+    if (!('lastUpdated' in value) || value['lastUpdated'] === undefined)
+        return false;
+    return true;
+}
+function ConversationThreads200ResponseThreadsInnerFromJSON(json) {
+    return ConversationThreads200ResponseThreadsInnerFromJSONTyped(json, false);
+}
+function ConversationThreads200ResponseThreadsInnerFromJSONTyped(json, ignoreDiscriminator) {
+    if (json == null) {
+        return json;
+    }
+    return {
+        'threadId': json['thread_id'],
+        'title': json['title'],
+        'lastUpdated': json['last_updated'],
+    };
+}
+function ConversationThreads200ResponseThreadsInnerToJSON(json) {
+    return ConversationThreads200ResponseThreadsInnerToJSONTyped(json, false);
+}
+function ConversationThreads200ResponseThreadsInnerToJSONTyped(value, ignoreDiscriminator) {
+    if (ignoreDiscriminator === void 0) { ignoreDiscriminator = false; }
+    if (value == null) {
+        return value;
+    }
+    return {
+        'thread_id': value['threadId'],
+        'title': value['title'],
+        'last_updated': value['lastUpdated'],
+    };
+}

package/dist/models/EditFloor400Response.d.ts

@@ -1,6 +1,8 @@
 /**
  * Floor Memory
- * The set APIs are used to develop Floor pds which can be used as their personal assistants.   This set of APIs are divided into two parts.  - Memory and  - Registration.   The developer has two ways of using the APIs for the app development. Developer can choose to the  Registration APIs for using the existing xfloor infracture or can implement custom Registration process. In the case of custom registration process, the developer is bound to provide proper authentication mechanisms and then send the user information to xlfoor.
+ * The set APIs are used to develop Floor pds which can be used as their personal assistants. This set of APIs are divided into two parts.
+ * - Memory and
+ * - Registration. The developer has two ways of using the APIs for the app development. Developer can choose to the Registration APIs for using the existing xfloor infracture or can implement custom Registration process. In the case of custom registration process, the developer is bound to provide proper authentication mechanisms and then send the user information to xlfoor.
  *
  * The version of the OpenAPI document: 1.0.0
  * Contact: contact@ipomo.in