@xfloor/floor-memory-sdk-ts 1.0.6 → 1.0.8

package/README.md

@@ -1,6 +1,6 @@
-# @xfloor/floor-memory-sdk-ts@1.0.6
+# @xfloor/floor-memory-sdk-ts@1.0.8
 
-A TypeScript SDK client for the appfloor.in API.
+A TypeScript SDK client for the localhost API.
 
 ### Usage
 
@@ -48,7 +48,7 @@ example().catch(console.error);
 
 ### API Endpoints
 
-All URIs are relative to *https://appfloor.in*
+All URIs are relative to *http://localhost*
 
 | Class | Method | HTTP request |
 
@@ -246,7 +246,7 @@ and is automatically generated by the
 [OpenAPI Generator](https://openapi-generator.tech) project:
 
 - API version: `1.0.0`
-- Package version: `1.0.6`
+- Package version: `1.0.8`
 - Generator version: `7.18.0`
 - Build package: `org.openapitools.codegen.languages.TypeScriptFetchClientCodegen`
 

package/dist/apis/EventApi.d.ts

@@ -15,6 +15,7 @@ import * as runtime from '../runtime';
 import type { EventResponse } from '../models/index';
 export interface EventRequest {
     inputInfo: string;
+    appId: string;
     files?: Blob;
 }
 /**
@@ -22,12 +23,12 @@ export interface EventRequest {
  */
 export declare class EventApi extends runtime.BaseAPI {
     /**
-     * ## 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 (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\": \"1\",   \"user_id\": \"145623907625\",   \"title\": \"My note\",   \"description\": \"Things I should remember\" } ```  ---  ## 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., `0 for post`, `1 for forum`). 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)
      */
     eventRaw(requestParameters: EventRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<runtime.ApiResponse<EventResponse>>;
     /**
-     * ## 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 (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\": \"1\",   \"user_id\": \"145623907625\",   \"title\": \"My note\",   \"description\": \"Things I should remember\" } ```  ---  ## 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., `0 for post`, `1 for forum`). 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)
      */
     event(requestParameters: EventRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<EventResponse>;

package/dist/apis/EventApi.js

@@ -78,7 +78,7 @@ var EventApi = /** @class */ (function (_super) {
         return _super !== null && _super.apply(this, arguments) || this;
     }
     /**
-     * ## 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 (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\": \"1\",   \"user_id\": \"145623907625\",   \"title\": \"My note\",   \"description\": \"Things I should remember\" } ```  ---  ## 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., `0 for post`, `1 for forum`). 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) {
@@ -90,6 +90,9 @@ var EventApi = /** @class */ (function (_super) {
                         if (requestParameters['inputInfo'] == null) {
                             throw new runtime.RequiredError('inputInfo', 'Required parameter "inputInfo" was null or undefined when calling event().');
                         }
+                        if (requestParameters['appId'] == null) {
+                            throw new runtime.RequiredError('appId', 'Required parameter "appId" was null or undefined when calling event().');
+                        }
                         queryParameters = {};
                         headerParameters = {};
                         if (!(this.configuration && this.configuration.accessToken)) return [3 /*break*/, 2];
@@ -121,6 +124,9 @@ var EventApi = /** @class */ (function (_super) {
                         if (requestParameters['inputInfo'] != null) {
                             formParams.append('input_info', requestParameters['inputInfo']);
                         }
+                        if (requestParameters['appId'] != null) {
+                            formParams.append('app_id', requestParameters['appId']);
+                        }
                         urlPath = "/api/memory/events";
                         return [4 /*yield*/, this.request({
                                 path: urlPath,
@@ -137,7 +143,7 @@ var EventApi = /** @class */ (function (_super) {
         });
     };
     /**
-     * ## 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 (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\": \"1\",   \"user_id\": \"145623907625\",   \"title\": \"My note\",   \"description\": \"Things I should remember\" } ```  ---  ## 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., `0 for post`, `1 for forum`). 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/QueryApi.d.ts

@@ -21,12 +21,12 @@ export interface QueryOperationRequest {
  */
 export declare class QueryApi extends runtime.BaseAPI {
     /**
-     * # **Conversational Query API** This is the **core API** of xfloor.  It accepts a natural language query and returns a conversational response derived from: - Content ingested into the specified Floor - The user’s prior conversation history (if provided) - Relevant metadata and context  This API is designed for **multi-turn conversations** and can be used to build: - AI chatbots - Knowledge assistants - Floor-specific copilots  This API enables **conversational, context-aware querying** over data stored within xfloor.  It accepts a natural language query (for example, *“What options do I have in your institute?”*) and returns relevant information derived from the specified floors and their associated content.  The API is designed for **multi-turn conversations**. Follow-up questions from the same user automatically build upon prior context, allowing the system to refine, expand, or clarify results across successive calls.  ---  ## **Core Capabilities**  * Interprets **natural language queries** * Retrieves relevant information from one or more floors * Applies **time-, type-, and tag-based filters** * Supports **Top-K retrieval** for result control * Optionally includes metadata with responses * Can generate **summarized responses** when requested * Maintains **conversation continuity** across multiple queries from the same user  ---  ## **Authentication & Identity**  * A valid `user_id` is **required** * User authentication is assumed to be completed **before** calling this API * `app_id` identifies the calling application context * Conversational continuity is maintained **per `user_id`**  > **Note:** All queries from the same `user_id` are treated as part of a single conversational context unless explicitly reset by the application.  ---  ## **Request Contract**  ### **HTTP Method**  `POST`  ### **Content-Type**  ``` application/json ```  > **Important:** > This API accepts **JSON requests only**. > `multipart/form-data` is **not supported**.  ---  ## **Request Body (JSON)**  ### **Field Descriptions**  | Field               | Type                    | Required | Description                                                                                    | | ------------------- | ----------------------- | -------- | ---------------------------------------------------------------------------------------------- | | `user_id`           | string                  | Yes      | Unique xfloor user identifier. Used to maintain conversational continuity and personalization. | | `query`             | string                  | Yes      | Natural language query provided by the user.                                                   | | `floor_ids`         | array of strings        | Yes      | List of floor identifiers that define the search scope. Must be provided as a JSON array.      | | `filters`           | object                  | Optional | Additional constraints to narrow search results.                                               | | `filters.time_from` | string (ISO-8601)       | Optional | Start timestamp for filtering content by creation or update time.                              | | `filters.time_to`   | string (ISO-8601)       | Optional | End timestamp for filtering content by creation or update time.                                | | `filters.types`     | array of strings        | Optional | Content types to include (e.g., `post`, `blog`, `forum`).                                      | | `filters.tags`      | array of strings        | Optional | Tags used to further refine results.                                                           | | `k`                 | integer                 | Optional | Maximum number of results to retrieve (Top-K). Defaults to system-defined behavior if omitted. | | `include_metadata`  | string (`\"0\"` or `\"1\"`) | Optional | Whether to include metadata (source, timestamps, tags) in the response. Defaults to `\"0\"`.     | | `summary_needed`    | string (`\"0\"` or `\"1\"`) | Optional | Whether a summarized conversational answer should be generated. Defaults to `\"0\"`.             | | `app_id`            | string                  | Optional | Identifies the application invoking the API. Useful for multi-app integrations.                |  ---  ### **Important Encoding Rules**  * `floor_ids` **must** be provided as a JSON array    ```json   \"floor_ids\": [\"floor_1\", \"floor_2\"]   ``` * Boolean-style flags (`include_metadata`, `summary_needed`) are encoded as **string values**: `\"0\"` or `\"1\"` * `filters` must be provided as a **JSON object**, not a string  ---  ### **Canonical Request Example**  ```json {   \"user_id\": \"xf_user_123\",   \"query\": \"What options do I have in your institute?\",   \"floor_ids\": [\"institute_floor\"],   \"filters\": {     \"types\": [\"post\", \"blog\"],     \"tags\": [\"admissions\"]   },   \"k\": 5,   \"include_metadata\": \"1\",   \"summary_needed\": \"1\",   \"app_id\": \"student_portal\" } ```  ---  ## **Behavior**  1. The query is analyzed using conversational and semantic understanding. 2. Relevant content is retrieved from the specified floors. 3. Filters (time, type, tags) are applied if provided. 4. Results are ranked and limited based on `k`. 5. If `summary_needed = \"1\"`, a synthesized conversational summary is generated. 6. If `include_metadata = \"1\"`, metadata is attached to each result item. 7. The response is returned in a conversational format suitable for follow-up questions.  ---  ## **Response Contract**  ### **High-Level Response Structure**  ```json {   \"answer\": \"Assistant-generated conversational response\",   \"items\": [     {       \"id\": \"content_id\",       \"type\": \"post\",       \"text\": \"Original content snippet\",       \"metadata\": { }     }   ] } ```  ---  ### **Response Field Semantics**  | Field              | Always Present     | Description                                 | Rendering Guidance     | | ------------------ | ------------------ | ------------------------------------------- | ---------------------- | | `answer`           | Yes                | Assistant-generated conversational response | **Render prominently** | | `items`            | Yes (may be empty) | List of matched content used for grounding  | Render optionally      | | `items[].metadata` | Conditional        | Included only if `include_metadata = \"1\"`   | Render on demand       |  > **No-Result Case:** > If no relevant content is found, `items` will be an empty array and `answer` will contain a conversational fallback response.  ---  ## **Conversation Continuity**  * Conversation state is maintained **per `user_id`** * Follow-up queries automatically reference prior context * The API does not require explicit conversation IDs * Applications may reset conversation context by using a new `user_id`  ---  ## **Error Handling**  The API may return errors in the following cases:  * Missing or invalid `user_id` * Empty or unsupported `query` * Invalid or inaccessible `floor_ids` * Authorization or application context errors * Internal processing failures  All errors are returned with appropriate HTTP status codes and descriptive messages.  ---  ## **Typical Use Case Flow**  1. User asks an initial question    *“What options do I have in your institute?”* 2. Application calls `/agent/memory/query` 3. Results are displayed to the user 4. User asks a follow-up    *“Which ones are available on weekends?”* 5. Application calls the same API again with the new query 6. Conversation continues seamlessly using prior context  ---  ## **One-Line Summary**  > Executes a conversational query over xfloor content, returning context-aware, filtered, and optionally summarized results with support for multi-turn interactions.
+     * # **Conversational Query API** This is the **core API** of xfloor.  It accepts a natural language query and returns a conversational response derived from: - Content ingested into the specified Floor - The user’s prior conversation history (if provided) - Relevant metadata and context  This API is designed for **multi-turn conversations** and can be used to build: - AI chatbots - Knowledge assistants - Floor-specific copilots  This API enables **conversational, context-aware querying** over data stored within xfloor.  It accepts a natural language query (for example, *“What options do I have in your institute?”*) and returns relevant information derived from the specified floors and their associated content.  The API is designed for **multi-turn conversations**. Follow-up questions from the same user automatically build upon prior context, allowing the system to refine, expand, or clarify results across successive calls.  ---  ## **Core Capabilities**  * Interprets **natural language queries** * Retrieves relevant information from one or more floors * Applies **time-, type-, and tag-based filters** * Supports **Top-K retrieval** for result control * Optionally includes metadata with responses * Can generate **summarized responses** when requested * Maintains **conversation continuity** across multiple queries from the same user  ---  ## **Authentication & Identity**  * A valid `user_id` is **required** * User authentication is assumed to be completed **before** calling this API * `app_id` identifies the calling application context * Conversational continuity is maintained **per `user_id`**  > **Note:** All queries from the same `user_id` are treated as part of a single conversational context unless explicitly reset by the application.  ---  ## **Request Contract**  ### **HTTP Method**  `POST`  ### **Content-Type**  ``` application/json ```  > **Important:** > This API accepts **JSON requests only**. > `multipart/form-data` is **not supported**.  ---  ## **Request Body (JSON)**  ### **Field Descriptions**  | Field               | Type                    | Required | Description                                                                                    | | ------------------- | ----------------------- | -------- | ---------------------------------------------------------------------------------------------- | | `user_id`           | string                  | Yes      | Unique xfloor user identifier. Used to maintain conversational continuity and personalization. | | `query`             | string                  | Yes      | Natural language query provided by the user.                                                   | | `floor_ids`         | array of strings        | Yes      | List of floor identifiers that define the search scope. Must be provided as a JSON array.      | | `filters`           | object                  | Optional | Additional constraints to narrow search results.                                               | | `filters.time_from` | string (ISO-8601)       | Optional | Start timestamp for filtering content by creation or update time.                              | | `filters.time_to`   | string (ISO-8601)       | Optional | End timestamp for filtering content by creation or update time.                                | | `filters.types`     | array of strings        | Optional | Content types to include (e.g., `post`, `blog`, `forum`).                                      | | `filters.tags`      | array of strings        | Optional | Tags used to further refine results.                                                           | | `k`                 | integer                 | Optional | Maximum number of results to retrieve (Top-K). Defaults to system-defined behavior if omitted. | | `include_metadata`  | string (`\"0\"` or `\"1\"`) | Optional | Whether to include metadata (source, timestamps, tags) in the response. Defaults to `\"0\"`.     | | `summary_needed`    | string (`\"0\"` or `\"1\"`) | Optional | Whether a summarized conversational answer should be generated. Defaults to `\"0\"`.             | | `app_id`            | string                  | Optional | Identifies the application invoking the API. Useful for multi-app integrations.                |  ---  ### **Important Encoding Rules**  * `floor_ids` **must** be provided as a JSON array    ```json   \"floor_ids\": [\"floor_1\", \"floor_2\"]   ``` * Boolean-style flags (`include_metadata`, `summary_needed`) are encoded as **string values**: `\"0\"` or `\"1\"` * `filters` must be provided as a **JSON object**, not a string  ---  ### **Canonical Request Example**  ```json {   \"user_id\": \"xf_user_123\",   \"query\": \"What options do I have in your institute?\",   \"floor_ids\": [\"institute_floor\"],   \"filters\": {     \"types\": [\"post\", \"blog\"],     \"tags\": [\"admissions\"]   },   \"k\": 5,   \"include_metadata\": \"1\",   \"summary_needed\": \"1\",   \"app_id\": \"student_portal\" } ```  ---  ## **Behavior**  1. The query is analyzed using conversational and semantic understanding. 2. Relevant content is retrieved from the specified floors. 3. Filters (time, type, tags) are applied if provided. 4. Results are ranked and limited based on `k`. 5. If `summary_needed = \"1\"`, a synthesized conversational summary is generated. 6. If `include_metadata = \"1\"`, metadata is attached to each result item. 7. The response is returned in a conversational format suitable for follow-up questions.  ---  ## **Response Contract**  ### **High-Level Response Structure**  ```json {   \"answer\": \"Assistant-generated conversational response\",   \"items\": [     {       \"id\": \"content_id\",       \"type\": \"post\",       \"text\": \"Original content snippet\",       \"metadata\": { }     }   ] } ```  ---  ### **Response Field Semantics**  | Field              | Always Present     | Description                                 | Rendering Guidance     | | ------------------ | ------------------ | ------------------------------------------- | ---------------------- | | `answer`           | No                | Assistant-generated conversational response. Depends on summary_needed. Is present if summary_needed=1 | **Render prominently** | | `items`            | Yes (may be empty) | List of matched content used for grounding  | Render optionally      | | `items[].metadata` | Conditional        | Included only if `include_metadata = \"1\"`   | Render on demand       |  > **No-Result Case:** > If no relevant content is found, `items` will be an empty array and `answer` will contain a conversational fallback response.  ---  ## **Conversation Continuity**  * Conversation state is maintained **per `user_id`** * Follow-up queries automatically reference prior context * The API does not require explicit conversation IDs * Applications may reset conversation context by using a new `user_id`  ---  ## **Error Handling**  The API may return errors in the following cases:  * Missing or invalid `user_id` * Empty or unsupported `query` * Invalid or inaccessible `floor_ids` * Authorization or application context errors * Internal processing failures  All errors are returned with appropriate HTTP status codes and descriptive messages.  ---  ## **Typical Use Case Flow**  1. User asks an initial question    *“What options do I have in your institute?”* 2. Application calls `/agent/memory/query` 3. Results are displayed to the user 4. User asks a follow-up    *“Which ones are available on weekends?”* 5. Application calls the same API again with the new query 6. Conversation continues seamlessly using prior context  ---  ## **One-Line Summary**  > Executes a conversational query over xfloor content, returning context-aware, filtered, and optionally summarized results with support for multi-turn interactions.
      * Query (Primary API)
      */
     queryRaw(requestParameters: QueryOperationRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<runtime.ApiResponse<QueryResponse>>;
     /**
-     * # **Conversational Query API** This is the **core API** of xfloor.  It accepts a natural language query and returns a conversational response derived from: - Content ingested into the specified Floor - The user’s prior conversation history (if provided) - Relevant metadata and context  This API is designed for **multi-turn conversations** and can be used to build: - AI chatbots - Knowledge assistants - Floor-specific copilots  This API enables **conversational, context-aware querying** over data stored within xfloor.  It accepts a natural language query (for example, *“What options do I have in your institute?”*) and returns relevant information derived from the specified floors and their associated content.  The API is designed for **multi-turn conversations**. Follow-up questions from the same user automatically build upon prior context, allowing the system to refine, expand, or clarify results across successive calls.  ---  ## **Core Capabilities**  * Interprets **natural language queries** * Retrieves relevant information from one or more floors * Applies **time-, type-, and tag-based filters** * Supports **Top-K retrieval** for result control * Optionally includes metadata with responses * Can generate **summarized responses** when requested * Maintains **conversation continuity** across multiple queries from the same user  ---  ## **Authentication & Identity**  * A valid `user_id` is **required** * User authentication is assumed to be completed **before** calling this API * `app_id` identifies the calling application context * Conversational continuity is maintained **per `user_id`**  > **Note:** All queries from the same `user_id` are treated as part of a single conversational context unless explicitly reset by the application.  ---  ## **Request Contract**  ### **HTTP Method**  `POST`  ### **Content-Type**  ``` application/json ```  > **Important:** > This API accepts **JSON requests only**. > `multipart/form-data` is **not supported**.  ---  ## **Request Body (JSON)**  ### **Field Descriptions**  | Field               | Type                    | Required | Description                                                                                    | | ------------------- | ----------------------- | -------- | ---------------------------------------------------------------------------------------------- | | `user_id`           | string                  | Yes      | Unique xfloor user identifier. Used to maintain conversational continuity and personalization. | | `query`             | string                  | Yes      | Natural language query provided by the user.                                                   | | `floor_ids`         | array of strings        | Yes      | List of floor identifiers that define the search scope. Must be provided as a JSON array.      | | `filters`           | object                  | Optional | Additional constraints to narrow search results.                                               | | `filters.time_from` | string (ISO-8601)       | Optional | Start timestamp for filtering content by creation or update time.                              | | `filters.time_to`   | string (ISO-8601)       | Optional | End timestamp for filtering content by creation or update time.                                | | `filters.types`     | array of strings        | Optional | Content types to include (e.g., `post`, `blog`, `forum`).                                      | | `filters.tags`      | array of strings        | Optional | Tags used to further refine results.                                                           | | `k`                 | integer                 | Optional | Maximum number of results to retrieve (Top-K). Defaults to system-defined behavior if omitted. | | `include_metadata`  | string (`\"0\"` or `\"1\"`) | Optional | Whether to include metadata (source, timestamps, tags) in the response. Defaults to `\"0\"`.     | | `summary_needed`    | string (`\"0\"` or `\"1\"`) | Optional | Whether a summarized conversational answer should be generated. Defaults to `\"0\"`.             | | `app_id`            | string                  | Optional | Identifies the application invoking the API. Useful for multi-app integrations.                |  ---  ### **Important Encoding Rules**  * `floor_ids` **must** be provided as a JSON array    ```json   \"floor_ids\": [\"floor_1\", \"floor_2\"]   ``` * Boolean-style flags (`include_metadata`, `summary_needed`) are encoded as **string values**: `\"0\"` or `\"1\"` * `filters` must be provided as a **JSON object**, not a string  ---  ### **Canonical Request Example**  ```json {   \"user_id\": \"xf_user_123\",   \"query\": \"What options do I have in your institute?\",   \"floor_ids\": [\"institute_floor\"],   \"filters\": {     \"types\": [\"post\", \"blog\"],     \"tags\": [\"admissions\"]   },   \"k\": 5,   \"include_metadata\": \"1\",   \"summary_needed\": \"1\",   \"app_id\": \"student_portal\" } ```  ---  ## **Behavior**  1. The query is analyzed using conversational and semantic understanding. 2. Relevant content is retrieved from the specified floors. 3. Filters (time, type, tags) are applied if provided. 4. Results are ranked and limited based on `k`. 5. If `summary_needed = \"1\"`, a synthesized conversational summary is generated. 6. If `include_metadata = \"1\"`, metadata is attached to each result item. 7. The response is returned in a conversational format suitable for follow-up questions.  ---  ## **Response Contract**  ### **High-Level Response Structure**  ```json {   \"answer\": \"Assistant-generated conversational response\",   \"items\": [     {       \"id\": \"content_id\",       \"type\": \"post\",       \"text\": \"Original content snippet\",       \"metadata\": { }     }   ] } ```  ---  ### **Response Field Semantics**  | Field              | Always Present     | Description                                 | Rendering Guidance     | | ------------------ | ------------------ | ------------------------------------------- | ---------------------- | | `answer`           | Yes                | Assistant-generated conversational response | **Render prominently** | | `items`            | Yes (may be empty) | List of matched content used for grounding  | Render optionally      | | `items[].metadata` | Conditional        | Included only if `include_metadata = \"1\"`   | Render on demand       |  > **No-Result Case:** > If no relevant content is found, `items` will be an empty array and `answer` will contain a conversational fallback response.  ---  ## **Conversation Continuity**  * Conversation state is maintained **per `user_id`** * Follow-up queries automatically reference prior context * The API does not require explicit conversation IDs * Applications may reset conversation context by using a new `user_id`  ---  ## **Error Handling**  The API may return errors in the following cases:  * Missing or invalid `user_id` * Empty or unsupported `query` * Invalid or inaccessible `floor_ids` * Authorization or application context errors * Internal processing failures  All errors are returned with appropriate HTTP status codes and descriptive messages.  ---  ## **Typical Use Case Flow**  1. User asks an initial question    *“What options do I have in your institute?”* 2. Application calls `/agent/memory/query` 3. Results are displayed to the user 4. User asks a follow-up    *“Which ones are available on weekends?”* 5. Application calls the same API again with the new query 6. Conversation continues seamlessly using prior context  ---  ## **One-Line Summary**  > Executes a conversational query over xfloor content, returning context-aware, filtered, and optionally summarized results with support for multi-turn interactions.
+     * # **Conversational Query API** This is the **core API** of xfloor.  It accepts a natural language query and returns a conversational response derived from: - Content ingested into the specified Floor - The user’s prior conversation history (if provided) - Relevant metadata and context  This API is designed for **multi-turn conversations** and can be used to build: - AI chatbots - Knowledge assistants - Floor-specific copilots  This API enables **conversational, context-aware querying** over data stored within xfloor.  It accepts a natural language query (for example, *“What options do I have in your institute?”*) and returns relevant information derived from the specified floors and their associated content.  The API is designed for **multi-turn conversations**. Follow-up questions from the same user automatically build upon prior context, allowing the system to refine, expand, or clarify results across successive calls.  ---  ## **Core Capabilities**  * Interprets **natural language queries** * Retrieves relevant information from one or more floors * Applies **time-, type-, and tag-based filters** * Supports **Top-K retrieval** for result control * Optionally includes metadata with responses * Can generate **summarized responses** when requested * Maintains **conversation continuity** across multiple queries from the same user  ---  ## **Authentication & Identity**  * A valid `user_id` is **required** * User authentication is assumed to be completed **before** calling this API * `app_id` identifies the calling application context * Conversational continuity is maintained **per `user_id`**  > **Note:** All queries from the same `user_id` are treated as part of a single conversational context unless explicitly reset by the application.  ---  ## **Request Contract**  ### **HTTP Method**  `POST`  ### **Content-Type**  ``` application/json ```  > **Important:** > This API accepts **JSON requests only**. > `multipart/form-data` is **not supported**.  ---  ## **Request Body (JSON)**  ### **Field Descriptions**  | Field               | Type                    | Required | Description                                                                                    | | ------------------- | ----------------------- | -------- | ---------------------------------------------------------------------------------------------- | | `user_id`           | string                  | Yes      | Unique xfloor user identifier. Used to maintain conversational continuity and personalization. | | `query`             | string                  | Yes      | Natural language query provided by the user.                                                   | | `floor_ids`         | array of strings        | Yes      | List of floor identifiers that define the search scope. Must be provided as a JSON array.      | | `filters`           | object                  | Optional | Additional constraints to narrow search results.                                               | | `filters.time_from` | string (ISO-8601)       | Optional | Start timestamp for filtering content by creation or update time.                              | | `filters.time_to`   | string (ISO-8601)       | Optional | End timestamp for filtering content by creation or update time.                                | | `filters.types`     | array of strings        | Optional | Content types to include (e.g., `post`, `blog`, `forum`).                                      | | `filters.tags`      | array of strings        | Optional | Tags used to further refine results.                                                           | | `k`                 | integer                 | Optional | Maximum number of results to retrieve (Top-K). Defaults to system-defined behavior if omitted. | | `include_metadata`  | string (`\"0\"` or `\"1\"`) | Optional | Whether to include metadata (source, timestamps, tags) in the response. Defaults to `\"0\"`.     | | `summary_needed`    | string (`\"0\"` or `\"1\"`) | Optional | Whether a summarized conversational answer should be generated. Defaults to `\"0\"`.             | | `app_id`            | string                  | Optional | Identifies the application invoking the API. Useful for multi-app integrations.                |  ---  ### **Important Encoding Rules**  * `floor_ids` **must** be provided as a JSON array    ```json   \"floor_ids\": [\"floor_1\", \"floor_2\"]   ``` * Boolean-style flags (`include_metadata`, `summary_needed`) are encoded as **string values**: `\"0\"` or `\"1\"` * `filters` must be provided as a **JSON object**, not a string  ---  ### **Canonical Request Example**  ```json {   \"user_id\": \"xf_user_123\",   \"query\": \"What options do I have in your institute?\",   \"floor_ids\": [\"institute_floor\"],   \"filters\": {     \"types\": [\"post\", \"blog\"],     \"tags\": [\"admissions\"]   },   \"k\": 5,   \"include_metadata\": \"1\",   \"summary_needed\": \"1\",   \"app_id\": \"student_portal\" } ```  ---  ## **Behavior**  1. The query is analyzed using conversational and semantic understanding. 2. Relevant content is retrieved from the specified floors. 3. Filters (time, type, tags) are applied if provided. 4. Results are ranked and limited based on `k`. 5. If `summary_needed = \"1\"`, a synthesized conversational summary is generated. 6. If `include_metadata = \"1\"`, metadata is attached to each result item. 7. The response is returned in a conversational format suitable for follow-up questions.  ---  ## **Response Contract**  ### **High-Level Response Structure**  ```json {   \"answer\": \"Assistant-generated conversational response\",   \"items\": [     {       \"id\": \"content_id\",       \"type\": \"post\",       \"text\": \"Original content snippet\",       \"metadata\": { }     }   ] } ```  ---  ### **Response Field Semantics**  | Field              | Always Present     | Description                                 | Rendering Guidance     | | ------------------ | ------------------ | ------------------------------------------- | ---------------------- | | `answer`           | No                | Assistant-generated conversational response. Depends on summary_needed. Is present if summary_needed=1 | **Render prominently** | | `items`            | Yes (may be empty) | List of matched content used for grounding  | Render optionally      | | `items[].metadata` | Conditional        | Included only if `include_metadata = \"1\"`   | Render on demand       |  > **No-Result Case:** > If no relevant content is found, `items` will be an empty array and `answer` will contain a conversational fallback response.  ---  ## **Conversation Continuity**  * Conversation state is maintained **per `user_id`** * Follow-up queries automatically reference prior context * The API does not require explicit conversation IDs * Applications may reset conversation context by using a new `user_id`  ---  ## **Error Handling**  The API may return errors in the following cases:  * Missing or invalid `user_id` * Empty or unsupported `query` * Invalid or inaccessible `floor_ids` * Authorization or application context errors * Internal processing failures  All errors are returned with appropriate HTTP status codes and descriptive messages.  ---  ## **Typical Use Case Flow**  1. User asks an initial question    *“What options do I have in your institute?”* 2. Application calls `/agent/memory/query` 3. Results are displayed to the user 4. User asks a follow-up    *“Which ones are available on weekends?”* 5. Application calls the same API again with the new query 6. Conversation continues seamlessly using prior context  ---  ## **One-Line Summary**  > Executes a conversational query over xfloor content, returning context-aware, filtered, and optionally summarized results with support for multi-turn interactions.
      * Query (Primary API)
      */
     query(requestParameters: QueryOperationRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<QueryResponse>;

package/dist/apis/QueryApi.js

@@ -78,7 +78,7 @@ var QueryApi = /** @class */ (function (_super) {
         return _super !== null && _super.apply(this, arguments) || this;
     }
     /**
-     * # **Conversational Query API** This is the **core API** of xfloor.  It accepts a natural language query and returns a conversational response derived from: - Content ingested into the specified Floor - The user’s prior conversation history (if provided) - Relevant metadata and context  This API is designed for **multi-turn conversations** and can be used to build: - AI chatbots - Knowledge assistants - Floor-specific copilots  This API enables **conversational, context-aware querying** over data stored within xfloor.  It accepts a natural language query (for example, *“What options do I have in your institute?”*) and returns relevant information derived from the specified floors and their associated content.  The API is designed for **multi-turn conversations**. Follow-up questions from the same user automatically build upon prior context, allowing the system to refine, expand, or clarify results across successive calls.  ---  ## **Core Capabilities**  * Interprets **natural language queries** * Retrieves relevant information from one or more floors * Applies **time-, type-, and tag-based filters** * Supports **Top-K retrieval** for result control * Optionally includes metadata with responses * Can generate **summarized responses** when requested * Maintains **conversation continuity** across multiple queries from the same user  ---  ## **Authentication & Identity**  * A valid `user_id` is **required** * User authentication is assumed to be completed **before** calling this API * `app_id` identifies the calling application context * Conversational continuity is maintained **per `user_id`**  > **Note:** All queries from the same `user_id` are treated as part of a single conversational context unless explicitly reset by the application.  ---  ## **Request Contract**  ### **HTTP Method**  `POST`  ### **Content-Type**  ``` application/json ```  > **Important:** > This API accepts **JSON requests only**. > `multipart/form-data` is **not supported**.  ---  ## **Request Body (JSON)**  ### **Field Descriptions**  | Field               | Type                    | Required | Description                                                                                    | | ------------------- | ----------------------- | -------- | ---------------------------------------------------------------------------------------------- | | `user_id`           | string                  | Yes      | Unique xfloor user identifier. Used to maintain conversational continuity and personalization. | | `query`             | string                  | Yes      | Natural language query provided by the user.                                                   | | `floor_ids`         | array of strings        | Yes      | List of floor identifiers that define the search scope. Must be provided as a JSON array.      | | `filters`           | object                  | Optional | Additional constraints to narrow search results.                                               | | `filters.time_from` | string (ISO-8601)       | Optional | Start timestamp for filtering content by creation or update time.                              | | `filters.time_to`   | string (ISO-8601)       | Optional | End timestamp for filtering content by creation or update time.                                | | `filters.types`     | array of strings        | Optional | Content types to include (e.g., `post`, `blog`, `forum`).                                      | | `filters.tags`      | array of strings        | Optional | Tags used to further refine results.                                                           | | `k`                 | integer                 | Optional | Maximum number of results to retrieve (Top-K). Defaults to system-defined behavior if omitted. | | `include_metadata`  | string (`\"0\"` or `\"1\"`) | Optional | Whether to include metadata (source, timestamps, tags) in the response. Defaults to `\"0\"`.     | | `summary_needed`    | string (`\"0\"` or `\"1\"`) | Optional | Whether a summarized conversational answer should be generated. Defaults to `\"0\"`.             | | `app_id`            | string                  | Optional | Identifies the application invoking the API. Useful for multi-app integrations.                |  ---  ### **Important Encoding Rules**  * `floor_ids` **must** be provided as a JSON array    ```json   \"floor_ids\": [\"floor_1\", \"floor_2\"]   ``` * Boolean-style flags (`include_metadata`, `summary_needed`) are encoded as **string values**: `\"0\"` or `\"1\"` * `filters` must be provided as a **JSON object**, not a string  ---  ### **Canonical Request Example**  ```json {   \"user_id\": \"xf_user_123\",   \"query\": \"What options do I have in your institute?\",   \"floor_ids\": [\"institute_floor\"],   \"filters\": {     \"types\": [\"post\", \"blog\"],     \"tags\": [\"admissions\"]   },   \"k\": 5,   \"include_metadata\": \"1\",   \"summary_needed\": \"1\",   \"app_id\": \"student_portal\" } ```  ---  ## **Behavior**  1. The query is analyzed using conversational and semantic understanding. 2. Relevant content is retrieved from the specified floors. 3. Filters (time, type, tags) are applied if provided. 4. Results are ranked and limited based on `k`. 5. If `summary_needed = \"1\"`, a synthesized conversational summary is generated. 6. If `include_metadata = \"1\"`, metadata is attached to each result item. 7. The response is returned in a conversational format suitable for follow-up questions.  ---  ## **Response Contract**  ### **High-Level Response Structure**  ```json {   \"answer\": \"Assistant-generated conversational response\",   \"items\": [     {       \"id\": \"content_id\",       \"type\": \"post\",       \"text\": \"Original content snippet\",       \"metadata\": { }     }   ] } ```  ---  ### **Response Field Semantics**  | Field              | Always Present     | Description                                 | Rendering Guidance     | | ------------------ | ------------------ | ------------------------------------------- | ---------------------- | | `answer`           | Yes                | Assistant-generated conversational response | **Render prominently** | | `items`            | Yes (may be empty) | List of matched content used for grounding  | Render optionally      | | `items[].metadata` | Conditional        | Included only if `include_metadata = \"1\"`   | Render on demand       |  > **No-Result Case:** > If no relevant content is found, `items` will be an empty array and `answer` will contain a conversational fallback response.  ---  ## **Conversation Continuity**  * Conversation state is maintained **per `user_id`** * Follow-up queries automatically reference prior context * The API does not require explicit conversation IDs * Applications may reset conversation context by using a new `user_id`  ---  ## **Error Handling**  The API may return errors in the following cases:  * Missing or invalid `user_id` * Empty or unsupported `query` * Invalid or inaccessible `floor_ids` * Authorization or application context errors * Internal processing failures  All errors are returned with appropriate HTTP status codes and descriptive messages.  ---  ## **Typical Use Case Flow**  1. User asks an initial question    *“What options do I have in your institute?”* 2. Application calls `/agent/memory/query` 3. Results are displayed to the user 4. User asks a follow-up    *“Which ones are available on weekends?”* 5. Application calls the same API again with the new query 6. Conversation continues seamlessly using prior context  ---  ## **One-Line Summary**  > Executes a conversational query over xfloor content, returning context-aware, filtered, and optionally summarized results with support for multi-turn interactions.
+     * # **Conversational Query API** This is the **core API** of xfloor.  It accepts a natural language query and returns a conversational response derived from: - Content ingested into the specified Floor - The user’s prior conversation history (if provided) - Relevant metadata and context  This API is designed for **multi-turn conversations** and can be used to build: - AI chatbots - Knowledge assistants - Floor-specific copilots  This API enables **conversational, context-aware querying** over data stored within xfloor.  It accepts a natural language query (for example, *“What options do I have in your institute?”*) and returns relevant information derived from the specified floors and their associated content.  The API is designed for **multi-turn conversations**. Follow-up questions from the same user automatically build upon prior context, allowing the system to refine, expand, or clarify results across successive calls.  ---  ## **Core Capabilities**  * Interprets **natural language queries** * Retrieves relevant information from one or more floors * Applies **time-, type-, and tag-based filters** * Supports **Top-K retrieval** for result control * Optionally includes metadata with responses * Can generate **summarized responses** when requested * Maintains **conversation continuity** across multiple queries from the same user  ---  ## **Authentication & Identity**  * A valid `user_id` is **required** * User authentication is assumed to be completed **before** calling this API * `app_id` identifies the calling application context * Conversational continuity is maintained **per `user_id`**  > **Note:** All queries from the same `user_id` are treated as part of a single conversational context unless explicitly reset by the application.  ---  ## **Request Contract**  ### **HTTP Method**  `POST`  ### **Content-Type**  ``` application/json ```  > **Important:** > This API accepts **JSON requests only**. > `multipart/form-data` is **not supported**.  ---  ## **Request Body (JSON)**  ### **Field Descriptions**  | Field               | Type                    | Required | Description                                                                                    | | ------------------- | ----------------------- | -------- | ---------------------------------------------------------------------------------------------- | | `user_id`           | string                  | Yes      | Unique xfloor user identifier. Used to maintain conversational continuity and personalization. | | `query`             | string                  | Yes      | Natural language query provided by the user.                                                   | | `floor_ids`         | array of strings        | Yes      | List of floor identifiers that define the search scope. Must be provided as a JSON array.      | | `filters`           | object                  | Optional | Additional constraints to narrow search results.                                               | | `filters.time_from` | string (ISO-8601)       | Optional | Start timestamp for filtering content by creation or update time.                              | | `filters.time_to`   | string (ISO-8601)       | Optional | End timestamp for filtering content by creation or update time.                                | | `filters.types`     | array of strings        | Optional | Content types to include (e.g., `post`, `blog`, `forum`).                                      | | `filters.tags`      | array of strings        | Optional | Tags used to further refine results.                                                           | | `k`                 | integer                 | Optional | Maximum number of results to retrieve (Top-K). Defaults to system-defined behavior if omitted. | | `include_metadata`  | string (`\"0\"` or `\"1\"`) | Optional | Whether to include metadata (source, timestamps, tags) in the response. Defaults to `\"0\"`.     | | `summary_needed`    | string (`\"0\"` or `\"1\"`) | Optional | Whether a summarized conversational answer should be generated. Defaults to `\"0\"`.             | | `app_id`            | string                  | Optional | Identifies the application invoking the API. Useful for multi-app integrations.                |  ---  ### **Important Encoding Rules**  * `floor_ids` **must** be provided as a JSON array    ```json   \"floor_ids\": [\"floor_1\", \"floor_2\"]   ``` * Boolean-style flags (`include_metadata`, `summary_needed`) are encoded as **string values**: `\"0\"` or `\"1\"` * `filters` must be provided as a **JSON object**, not a string  ---  ### **Canonical Request Example**  ```json {   \"user_id\": \"xf_user_123\",   \"query\": \"What options do I have in your institute?\",   \"floor_ids\": [\"institute_floor\"],   \"filters\": {     \"types\": [\"post\", \"blog\"],     \"tags\": [\"admissions\"]   },   \"k\": 5,   \"include_metadata\": \"1\",   \"summary_needed\": \"1\",   \"app_id\": \"student_portal\" } ```  ---  ## **Behavior**  1. The query is analyzed using conversational and semantic understanding. 2. Relevant content is retrieved from the specified floors. 3. Filters (time, type, tags) are applied if provided. 4. Results are ranked and limited based on `k`. 5. If `summary_needed = \"1\"`, a synthesized conversational summary is generated. 6. If `include_metadata = \"1\"`, metadata is attached to each result item. 7. The response is returned in a conversational format suitable for follow-up questions.  ---  ## **Response Contract**  ### **High-Level Response Structure**  ```json {   \"answer\": \"Assistant-generated conversational response\",   \"items\": [     {       \"id\": \"content_id\",       \"type\": \"post\",       \"text\": \"Original content snippet\",       \"metadata\": { }     }   ] } ```  ---  ### **Response Field Semantics**  | Field              | Always Present     | Description                                 | Rendering Guidance     | | ------------------ | ------------------ | ------------------------------------------- | ---------------------- | | `answer`           | No                | Assistant-generated conversational response. Depends on summary_needed. Is present if summary_needed=1 | **Render prominently** | | `items`            | Yes (may be empty) | List of matched content used for grounding  | Render optionally      | | `items[].metadata` | Conditional        | Included only if `include_metadata = \"1\"`   | Render on demand       |  > **No-Result Case:** > If no relevant content is found, `items` will be an empty array and `answer` will contain a conversational fallback response.  ---  ## **Conversation Continuity**  * Conversation state is maintained **per `user_id`** * Follow-up queries automatically reference prior context * The API does not require explicit conversation IDs * Applications may reset conversation context by using a new `user_id`  ---  ## **Error Handling**  The API may return errors in the following cases:  * Missing or invalid `user_id` * Empty or unsupported `query` * Invalid or inaccessible `floor_ids` * Authorization or application context errors * Internal processing failures  All errors are returned with appropriate HTTP status codes and descriptive messages.  ---  ## **Typical Use Case Flow**  1. User asks an initial question    *“What options do I have in your institute?”* 2. Application calls `/agent/memory/query` 3. Results are displayed to the user 4. User asks a follow-up    *“Which ones are available on weekends?”* 5. Application calls the same API again with the new query 6. Conversation continues seamlessly using prior context  ---  ## **One-Line Summary**  > Executes a conversational query over xfloor content, returning context-aware, filtered, and optionally summarized results with support for multi-turn interactions.
      * Query (Primary API)
      */
     QueryApi.prototype.queryRaw = function (requestParameters, initOverrides) {
@@ -119,7 +119,7 @@ var QueryApi = /** @class */ (function (_super) {
         });
     };
     /**
-     * # **Conversational Query API** This is the **core API** of xfloor.  It accepts a natural language query and returns a conversational response derived from: - Content ingested into the specified Floor - The user’s prior conversation history (if provided) - Relevant metadata and context  This API is designed for **multi-turn conversations** and can be used to build: - AI chatbots - Knowledge assistants - Floor-specific copilots  This API enables **conversational, context-aware querying** over data stored within xfloor.  It accepts a natural language query (for example, *“What options do I have in your institute?”*) and returns relevant information derived from the specified floors and their associated content.  The API is designed for **multi-turn conversations**. Follow-up questions from the same user automatically build upon prior context, allowing the system to refine, expand, or clarify results across successive calls.  ---  ## **Core Capabilities**  * Interprets **natural language queries** * Retrieves relevant information from one or more floors * Applies **time-, type-, and tag-based filters** * Supports **Top-K retrieval** for result control * Optionally includes metadata with responses * Can generate **summarized responses** when requested * Maintains **conversation continuity** across multiple queries from the same user  ---  ## **Authentication & Identity**  * A valid `user_id` is **required** * User authentication is assumed to be completed **before** calling this API * `app_id` identifies the calling application context * Conversational continuity is maintained **per `user_id`**  > **Note:** All queries from the same `user_id` are treated as part of a single conversational context unless explicitly reset by the application.  ---  ## **Request Contract**  ### **HTTP Method**  `POST`  ### **Content-Type**  ``` application/json ```  > **Important:** > This API accepts **JSON requests only**. > `multipart/form-data` is **not supported**.  ---  ## **Request Body (JSON)**  ### **Field Descriptions**  | Field               | Type                    | Required | Description                                                                                    | | ------------------- | ----------------------- | -------- | ---------------------------------------------------------------------------------------------- | | `user_id`           | string                  | Yes      | Unique xfloor user identifier. Used to maintain conversational continuity and personalization. | | `query`             | string                  | Yes      | Natural language query provided by the user.                                                   | | `floor_ids`         | array of strings        | Yes      | List of floor identifiers that define the search scope. Must be provided as a JSON array.      | | `filters`           | object                  | Optional | Additional constraints to narrow search results.                                               | | `filters.time_from` | string (ISO-8601)       | Optional | Start timestamp for filtering content by creation or update time.                              | | `filters.time_to`   | string (ISO-8601)       | Optional | End timestamp for filtering content by creation or update time.                                | | `filters.types`     | array of strings        | Optional | Content types to include (e.g., `post`, `blog`, `forum`).                                      | | `filters.tags`      | array of strings        | Optional | Tags used to further refine results.                                                           | | `k`                 | integer                 | Optional | Maximum number of results to retrieve (Top-K). Defaults to system-defined behavior if omitted. | | `include_metadata`  | string (`\"0\"` or `\"1\"`) | Optional | Whether to include metadata (source, timestamps, tags) in the response. Defaults to `\"0\"`.     | | `summary_needed`    | string (`\"0\"` or `\"1\"`) | Optional | Whether a summarized conversational answer should be generated. Defaults to `\"0\"`.             | | `app_id`            | string                  | Optional | Identifies the application invoking the API. Useful for multi-app integrations.                |  ---  ### **Important Encoding Rules**  * `floor_ids` **must** be provided as a JSON array    ```json   \"floor_ids\": [\"floor_1\", \"floor_2\"]   ``` * Boolean-style flags (`include_metadata`, `summary_needed`) are encoded as **string values**: `\"0\"` or `\"1\"` * `filters` must be provided as a **JSON object**, not a string  ---  ### **Canonical Request Example**  ```json {   \"user_id\": \"xf_user_123\",   \"query\": \"What options do I have in your institute?\",   \"floor_ids\": [\"institute_floor\"],   \"filters\": {     \"types\": [\"post\", \"blog\"],     \"tags\": [\"admissions\"]   },   \"k\": 5,   \"include_metadata\": \"1\",   \"summary_needed\": \"1\",   \"app_id\": \"student_portal\" } ```  ---  ## **Behavior**  1. The query is analyzed using conversational and semantic understanding. 2. Relevant content is retrieved from the specified floors. 3. Filters (time, type, tags) are applied if provided. 4. Results are ranked and limited based on `k`. 5. If `summary_needed = \"1\"`, a synthesized conversational summary is generated. 6. If `include_metadata = \"1\"`, metadata is attached to each result item. 7. The response is returned in a conversational format suitable for follow-up questions.  ---  ## **Response Contract**  ### **High-Level Response Structure**  ```json {   \"answer\": \"Assistant-generated conversational response\",   \"items\": [     {       \"id\": \"content_id\",       \"type\": \"post\",       \"text\": \"Original content snippet\",       \"metadata\": { }     }   ] } ```  ---  ### **Response Field Semantics**  | Field              | Always Present     | Description                                 | Rendering Guidance     | | ------------------ | ------------------ | ------------------------------------------- | ---------------------- | | `answer`           | Yes                | Assistant-generated conversational response | **Render prominently** | | `items`            | Yes (may be empty) | List of matched content used for grounding  | Render optionally      | | `items[].metadata` | Conditional        | Included only if `include_metadata = \"1\"`   | Render on demand       |  > **No-Result Case:** > If no relevant content is found, `items` will be an empty array and `answer` will contain a conversational fallback response.  ---  ## **Conversation Continuity**  * Conversation state is maintained **per `user_id`** * Follow-up queries automatically reference prior context * The API does not require explicit conversation IDs * Applications may reset conversation context by using a new `user_id`  ---  ## **Error Handling**  The API may return errors in the following cases:  * Missing or invalid `user_id` * Empty or unsupported `query` * Invalid or inaccessible `floor_ids` * Authorization or application context errors * Internal processing failures  All errors are returned with appropriate HTTP status codes and descriptive messages.  ---  ## **Typical Use Case Flow**  1. User asks an initial question    *“What options do I have in your institute?”* 2. Application calls `/agent/memory/query` 3. Results are displayed to the user 4. User asks a follow-up    *“Which ones are available on weekends?”* 5. Application calls the same API again with the new query 6. Conversation continues seamlessly using prior context  ---  ## **One-Line Summary**  > Executes a conversational query over xfloor content, returning context-aware, filtered, and optionally summarized results with support for multi-turn interactions.
+     * # **Conversational Query API** This is the **core API** of xfloor.  It accepts a natural language query and returns a conversational response derived from: - Content ingested into the specified Floor - The user’s prior conversation history (if provided) - Relevant metadata and context  This API is designed for **multi-turn conversations** and can be used to build: - AI chatbots - Knowledge assistants - Floor-specific copilots  This API enables **conversational, context-aware querying** over data stored within xfloor.  It accepts a natural language query (for example, *“What options do I have in your institute?”*) and returns relevant information derived from the specified floors and their associated content.  The API is designed for **multi-turn conversations**. Follow-up questions from the same user automatically build upon prior context, allowing the system to refine, expand, or clarify results across successive calls.  ---  ## **Core Capabilities**  * Interprets **natural language queries** * Retrieves relevant information from one or more floors * Applies **time-, type-, and tag-based filters** * Supports **Top-K retrieval** for result control * Optionally includes metadata with responses * Can generate **summarized responses** when requested * Maintains **conversation continuity** across multiple queries from the same user  ---  ## **Authentication & Identity**  * A valid `user_id` is **required** * User authentication is assumed to be completed **before** calling this API * `app_id` identifies the calling application context * Conversational continuity is maintained **per `user_id`**  > **Note:** All queries from the same `user_id` are treated as part of a single conversational context unless explicitly reset by the application.  ---  ## **Request Contract**  ### **HTTP Method**  `POST`  ### **Content-Type**  ``` application/json ```  > **Important:** > This API accepts **JSON requests only**. > `multipart/form-data` is **not supported**.  ---  ## **Request Body (JSON)**  ### **Field Descriptions**  | Field               | Type                    | Required | Description                                                                                    | | ------------------- | ----------------------- | -------- | ---------------------------------------------------------------------------------------------- | | `user_id`           | string                  | Yes      | Unique xfloor user identifier. Used to maintain conversational continuity and personalization. | | `query`             | string                  | Yes      | Natural language query provided by the user.                                                   | | `floor_ids`         | array of strings        | Yes      | List of floor identifiers that define the search scope. Must be provided as a JSON array.      | | `filters`           | object                  | Optional | Additional constraints to narrow search results.                                               | | `filters.time_from` | string (ISO-8601)       | Optional | Start timestamp for filtering content by creation or update time.                              | | `filters.time_to`   | string (ISO-8601)       | Optional | End timestamp for filtering content by creation or update time.                                | | `filters.types`     | array of strings        | Optional | Content types to include (e.g., `post`, `blog`, `forum`).                                      | | `filters.tags`      | array of strings        | Optional | Tags used to further refine results.                                                           | | `k`                 | integer                 | Optional | Maximum number of results to retrieve (Top-K). Defaults to system-defined behavior if omitted. | | `include_metadata`  | string (`\"0\"` or `\"1\"`) | Optional | Whether to include metadata (source, timestamps, tags) in the response. Defaults to `\"0\"`.     | | `summary_needed`    | string (`\"0\"` or `\"1\"`) | Optional | Whether a summarized conversational answer should be generated. Defaults to `\"0\"`.             | | `app_id`            | string                  | Optional | Identifies the application invoking the API. Useful for multi-app integrations.                |  ---  ### **Important Encoding Rules**  * `floor_ids` **must** be provided as a JSON array    ```json   \"floor_ids\": [\"floor_1\", \"floor_2\"]   ``` * Boolean-style flags (`include_metadata`, `summary_needed`) are encoded as **string values**: `\"0\"` or `\"1\"` * `filters` must be provided as a **JSON object**, not a string  ---  ### **Canonical Request Example**  ```json {   \"user_id\": \"xf_user_123\",   \"query\": \"What options do I have in your institute?\",   \"floor_ids\": [\"institute_floor\"],   \"filters\": {     \"types\": [\"post\", \"blog\"],     \"tags\": [\"admissions\"]   },   \"k\": 5,   \"include_metadata\": \"1\",   \"summary_needed\": \"1\",   \"app_id\": \"student_portal\" } ```  ---  ## **Behavior**  1. The query is analyzed using conversational and semantic understanding. 2. Relevant content is retrieved from the specified floors. 3. Filters (time, type, tags) are applied if provided. 4. Results are ranked and limited based on `k`. 5. If `summary_needed = \"1\"`, a synthesized conversational summary is generated. 6. If `include_metadata = \"1\"`, metadata is attached to each result item. 7. The response is returned in a conversational format suitable for follow-up questions.  ---  ## **Response Contract**  ### **High-Level Response Structure**  ```json {   \"answer\": \"Assistant-generated conversational response\",   \"items\": [     {       \"id\": \"content_id\",       \"type\": \"post\",       \"text\": \"Original content snippet\",       \"metadata\": { }     }   ] } ```  ---  ### **Response Field Semantics**  | Field              | Always Present     | Description                                 | Rendering Guidance     | | ------------------ | ------------------ | ------------------------------------------- | ---------------------- | | `answer`           | No                | Assistant-generated conversational response. Depends on summary_needed. Is present if summary_needed=1 | **Render prominently** | | `items`            | Yes (may be empty) | List of matched content used for grounding  | Render optionally      | | `items[].metadata` | Conditional        | Included only if `include_metadata = \"1\"`   | Render on demand       |  > **No-Result Case:** > If no relevant content is found, `items` will be an empty array and `answer` will contain a conversational fallback response.  ---  ## **Conversation Continuity**  * Conversation state is maintained **per `user_id`** * Follow-up queries automatically reference prior context * The API does not require explicit conversation IDs * Applications may reset conversation context by using a new `user_id`  ---  ## **Error Handling**  The API may return errors in the following cases:  * Missing or invalid `user_id` * Empty or unsupported `query` * Invalid or inaccessible `floor_ids` * Authorization or application context errors * Internal processing failures  All errors are returned with appropriate HTTP status codes and descriptive messages.  ---  ## **Typical Use Case Flow**  1. User asks an initial question    *“What options do I have in your institute?”* 2. Application calls `/agent/memory/query` 3. Results are displayed to the user 4. User asks a follow-up    *“Which ones are available on weekends?”* 5. Application calls the same API again with the new query 6. Conversation continues seamlessly using prior context  ---  ## **One-Line Summary**  > Executes a conversational query over xfloor content, returning context-aware, filtered, and optionally summarized results with support for multi-turn interactions.
      * Query (Primary API)
      */
     QueryApi.prototype.query = function (requestParameters, initOverrides) {

package/dist/models/FloorInfo.d.ts

@@ -42,7 +42,7 @@ export interface FloorInfo {
      * @type {string}
      * @memberof FloorInfo
      */
-    fid: string;
+    floorUid: string;
     /**
      * List of blocks
      * @type {Array<BlockDetails>}

package/dist/models/FloorInfo.js

@@ -30,7 +30,7 @@ function instanceOfFloorInfo(value) {
         return false;
     if (!('title' in value) || value['title'] === undefined)
         return false;
-    if (!('fid' in value) || value['fid'] === undefined)
+    if (!('floorUid' in value) || value['floorUid'] === undefined)
         return false;
     return true;
 }
@@ -45,7 +45,7 @@ function FloorInfoFromJSONTyped(json, ignoreDiscriminator) {
         'floorId': json['floor_id'],
         'title': json['title'],
         'details': json['details'] == null ? undefined : json['details'],
-        'fid': json['fid'],
+        'floorUid': json['floor_uid'],
         'blocks': json['blocks'] == null ? undefined : (json['blocks'].map(BlockDetails_1.BlockDetailsFromJSON)),
         'avatar': json['avatar'] == null ? undefined : (0, Media_1.MediaFromJSON)(json['avatar']),
     };
@@ -62,7 +62,7 @@ function FloorInfoToJSONTyped(value, ignoreDiscriminator) {
         'floor_id': value['floorId'],
         'title': value['title'],
         'details': value['details'],
-        'fid': value['fid'],
+        'floor_uid': value['floorUid'],
         'blocks': value['blocks'] == null ? undefined : (value['blocks'].map(BlockDetails_1.BlockDetailsToJSON)),
         'avatar': (0, Media_1.MediaToJSON)(value['avatar']),
     };

package/dist/models/GetFloorInformation200Response.d.ts

@@ -42,7 +42,7 @@ export interface GetFloorInformation200Response {
      * @type {string}
      * @memberof GetFloorInformation200Response
      */
-    fid: string;
+    floorUid: string;
     /**
      * List of blocks
      * @type {Array<BlockDetails>}

package/dist/models/GetFloorInformation200Response.js

@@ -30,7 +30,7 @@ function instanceOfGetFloorInformation200Response(value) {
         return false;
     if (!('title' in value) || value['title'] === undefined)
         return false;
-    if (!('fid' in value) || value['fid'] === undefined)
+    if (!('floorUid' in value) || value['floorUid'] === undefined)
         return false;
     return true;
 }
@@ -45,7 +45,7 @@ function GetFloorInformation200ResponseFromJSONTyped(json, ignoreDiscriminator)
         'floorId': json['floor_id'],
         'title': json['title'],
         'details': json['details'] == null ? undefined : json['details'],
-        'fid': json['fid'],
+        'floorUid': json['floor_uid'],
         'blocks': json['blocks'] == null ? undefined : (json['blocks'].map(BlockDetails_1.BlockDetailsFromJSON)),
         'avatar': json['avatar'] == null ? undefined : (0, Media_1.MediaFromJSON)(json['avatar']),
     };
@@ -62,7 +62,7 @@ function GetFloorInformation200ResponseToJSONTyped(value, ignoreDiscriminator) {
         'floor_id': value['floorId'],
         'title': value['title'],
         'details': value['details'],
-        'fid': value['fid'],
+        'floor_uid': value['floorUid'],
         'blocks': value['blocks'] == null ? undefined : (value['blocks'].map(BlockDetails_1.BlockDetailsToJSON)),
         'avatar': (0, Media_1.MediaToJSON)(value['avatar']),
     };

package/dist/models/Media.d.ts

@@ -24,7 +24,7 @@ export interface Media {
      */
     url: string;
     /**
-     * ID of the media
+     * Media Type
      * @type {string}
      * @memberof Media
      */

package/dist/runtime.js

@@ -82,7 +82,7 @@ exports.querystring = querystring;
 exports.exists = exists;
 exports.mapValues = mapValues;
 exports.canConsumeForm = canConsumeForm;
-exports.BASE_PATH = "https://appfloor.in".replace(/\/+$/, "");
+exports.BASE_PATH = "http://localhost".replace(/\/+$/, "");
 var Configuration = /** @class */ (function () {
     function Configuration(configuration) {
         if (configuration === void 0) { configuration = {}; }

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@xfloor/floor-memory-sdk-ts",
-  "version": "1.0.6",
+  "version": "1.0.8",
   "description": "TypeScript SDK for xFloor Memory APIs (Memory + Registration).",
   "author": "xFloor",
   "repository": {