@xfloor/floor-memory-sdk-ts 1.0.20 → 1.0.22

package/README.md

@@ -1,4 +1,4 @@
-# @xfloor/floor-memory-sdk-ts@1.0.20
+# @xfloor/floor-memory-sdk-ts@1.0.22
 A TypeScript SDK client for the appfloor.in API.
 
 ### Usage
@@ -15,7 +15,7 @@ Next, try it out.
 ```ts
 import {
   Configuration,
-  DefaultApi,
+  AuthApi,
 } from '@xfloor/floor-memory-sdk-ts';
 import type { ChangeEmailRequest } from '@xfloor/floor-memory-sdk-ts';
 
@@ -25,7 +25,7 @@ async function example() {
     // Configure HTTP bearer authorization: bearer
     accessToken: "YOUR BEARER TOKEN",
   });
-  const api = new DefaultApi(config);
+  const api = new AuthApi(config);
 
   const body = {
     // string | New Email ID
@@ -59,86 +59,86 @@ Description
 | ----- | ------ | ------------ |
 
 -------------
-*DefaultApi*
+*AuthApi*
 
-| [**changeEmail**](docs/DefaultApi.md#changeemail) | **POST** /auth-service/change/email |
+| [**changeEmail**](docs/AuthApi.md#changeemail) | **POST** /auth-service/change/email |
 
 Change email ID
-*DefaultApi*
+*AuthApi*
 
-| [**changeMobileNumber**](docs/DefaultApi.md#changemobilenumber) | **POST** /auth-service/change/mobile |
+| [**changeMobileNumber**](docs/AuthApi.md#changemobilenumber) | **POST** /auth-service/change/mobile |
 
 Change Mobile number
-*DefaultApi*
+*AuthApi*
 
-| [**changePassword**](docs/DefaultApi.md#changepassword) | **POST** /auth-service/password/change |
+| [**changePassword**](docs/AuthApi.md#changepassword) | **POST** /auth-service/password/change |
 
 Change Password
-*DefaultApi*
+*AuthApi*
 
-| [**makeFloorPrivate**](docs/DefaultApi.md#makefloorprivate) | **POST** /api/memory/make/floor/private/{floor_id} |
-
-Make floor Private
-*DefaultApi*
-
-| [**makeFloorPublic**](docs/DefaultApi.md#makefloorpublic) | **POST** /api/memory/make/floor/public/{floor_id} |
-
-Make floor public
-*DefaultApi*
-
-| [**renameFloor**](docs/DefaultApi.md#renamefloor) | **POST** /api/memory/change/floor/id |
-
-Rename floor
-*DefaultApi*
-
-| [**resetPassword**](docs/DefaultApi.md#resetpassword) | **POST** /auth-service/password/reset |
+| [**resetPassword**](docs/AuthApi.md#resetpassword) | **POST** /auth-service/password/reset |
 
 Reset Password
-*DefaultApi*
+*AuthApi*
 
-| [**sendValidationCode**](docs/DefaultApi.md#sendvalidationcode) | **POST** /auth-service/send/validation/code |
+| [**sendValidationCode**](docs/AuthApi.md#sendvalidationcode) | **POST** /auth-service/send/validation/code |
 
 Send Validation code
-*DefaultApi*
+*AuthApi*
 
-| [**signInWithEmail**](docs/DefaultApi.md#signinwithemail) | **POST** /auth-service/sign/in/with/email |
+| [**signInWithEmail**](docs/AuthApi.md#signinwithemail) | **POST** /auth-service/sign/in/with/email |
 
 Sign In with email ID
-*DefaultApi*
+*AuthApi*
 
-| [**signInWithMobileNumber**](docs/DefaultApi.md#signinwithmobilenumber) | **POST** /auth-service/sign/in/with/mobile/number |
+| [**signInWithMobileNumber**](docs/AuthApi.md#signinwithmobilenumber) | **POST** /auth-service/sign/in/with/mobile/number |
 
 Sign In with Mobile number
-*DefaultApi*
+*AuthApi*
 
-| [**signUp**](docs/DefaultApi.md#signup) | **POST** /auth-service/sign/up |
+| [**signUp**](docs/AuthApi.md#signup) | **POST** /auth-service/sign/up |
 
 Sign Up
-*DefaultApi*
+*AuthApi*
 
-| [**validateCode**](docs/DefaultApi.md#validatecode) | **POST** /auth-service/validate/activation/code |
+| [**validateCode**](docs/AuthApi.md#validatecode) | **POST** /auth-service/validate/activation/code |
 
 Validation
-*EditFloorApi*
-
-| [**editFloor**](docs/EditFloorApi.md#editfloor) | **POST** /api/memory/edit/floor/{floor_id} |
-
-Edit floor
 *EventApi*
 
 | [**event**](docs/EventApi.md#event) | **POST** /api/memory/events |
 
 Create Event (Post Content)
-*GetFloorInformationApi*
+*EventApi*
 
-| [**getFloorInformation**](docs/GetFloorInformationApi.md#getfloorinformation) | **GET** /api/memory/floor/info/{floor_id} |
+| [**getRecentEvents**](docs/EventApi.md#getrecentevents) | **GET** /api/memory/recent/events |
+
+Recent Events
+*FloorApi*
+
+| [**editFloor**](docs/FloorApi.md#editfloor) | **POST** /api/memory/edit/floor/{floor_id} |
+
+Edit floor
+*FloorApi*
+
+| [**getFloorInformation**](docs/FloorApi.md#getfloorinformation) | **GET** /api/memory/floor/info/{floor_id} |
 
 Basic information of a floor
-*GetRecentEventsApi*
+*FloorApi*
 
-| [**getRecentEvents**](docs/GetRecentEventsApi.md#getrecentevents) | **GET** /api/memory/recent/events |
+| [**makeFloorPrivate**](docs/FloorApi.md#makefloorprivate) | **POST** /api/memory/make/floor/private/{floor_id} |
 
-Recent Events
+Make floor Private
+*FloorApi*
+
+| [**makeFloorPublic**](docs/FloorApi.md#makefloorpublic) | **POST** /api/memory/make/floor/public/{floor_id} |
+
+Make floor public
+*FloorApi*
+
+| [**renameFloor**](docs/FloorApi.md#renamefloor) | **POST** /api/memory/change/floor/id |
+
+Rename floor
 *QueryApi*
 
 | [**query**](docs/QueryApi.md#queryoperation) | **POST** /agent/memory/query |
@@ -150,13 +150,13 @@ Query (Primary API)
 
 - [BlockDetails](docs/BlockDetails.md)
 - [ChangePassword200Response](docs/ChangePassword200Response.md)
+- [EditFloor200Response](docs/EditFloor200Response.md)
 - [EditFloor400Response](docs/EditFloor400Response.md)
 - [EditFloor400ResponseError](docs/EditFloor400ResponseError.md)
 - [Event400Response](docs/Event400Response.md)
 - [Event400ResponseError](docs/Event400ResponseError.md)
 - [EventResponse](docs/EventResponse.md)
 - [FloorInfo](docs/FloorInfo.md)
-- [GetFloorInformation200Response](docs/GetFloorInformation200Response.md)
 - [GetRecentEvents200Response](docs/GetRecentEvents200Response.md)
 - [GetRecentEvents200ResponseItemsInner](docs/GetRecentEvents200ResponseItemsInner.md)
 - [GetRecentEvents200ResponseItemsInnerAuthor](docs/GetRecentEvents200ResponseItemsInnerAuthor.md)
@@ -174,13 +174,13 @@ Query (Primary API)
 - [ResetPassword200Response](docs/ResetPassword200Response.md)
 - [ResetPassword400Response](docs/ResetPassword400Response.md)
 - [SendValidationCode200Response](docs/SendValidationCode200Response.md)
-- [SignInWithEmail200Response](docs/SignInWithEmail200Response.md)
-- [SignInWithEmail200ResponsePodInfo](docs/SignInWithEmail200ResponsePodInfo.md)
-- [SignInWithEmail200ResponseProfile](docs/SignInWithEmail200ResponseProfile.md)
-- [SignInWithEmail200ResponseProfileAvatar](docs/SignInWithEmail200ResponseProfileAvatar.md)
+- [SignInResponse](docs/SignInResponse.md)
 - [SignUp200Response](docs/SignUp200Response.md)
 - [SignUpResponse](docs/SignUpResponse.md)
 - [UserDetails](docs/UserDetails.md)
+- [UserDetailsPodInfo](docs/UserDetailsPodInfo.md)
+- [UserDetailsProfile](docs/UserDetailsProfile.md)
+- [UserDetailsProfileAvatar](docs/UserDetailsProfileAvatar.md)
 - [ValidateCode400Response](docs/ValidateCode400Response.md)
 - [ValidateCode400ResponseError](docs/ValidateCode400ResponseError.md)
 - [ValidateCode412Response](docs/ValidateCode412Response.md)
@@ -202,7 +202,7 @@ and is automatically generated by the
 [OpenAPI Generator](https://openapi-generator.tech) project:
 
 - API version: `1.0.0`
-- Package version: `1.0.20`
+- Package version: `1.0.22`
 - Generator version: `7.18.0`
 - Build package: `org.openapitools.codegen.languages.TypeScriptFetchClientCodegen`
 

package/dist/apis/{DefaultApi.d.ts → AuthApi.d.ts}

@@ -12,7 +12,7 @@
  * Do not edit the class manually.
  */
 import * as runtime from '../runtime';
-import type { ChangePassword200Response, GetFloorInformation200Response, ResetPassword200Response, SendValidationCode200Response, SignInWithEmail200Response, SignUp200Response, UserDetails } from '../models/index';
+import type { ChangePassword200Response, ResetPassword200Response, SendValidationCode200Response, SignInResponse, SignUp200Response, UserDetails } from '../models/index';
 export interface ChangeEmailRequest {
     newEmailId: string;
     activationCode: string;
@@ -26,22 +26,6 @@ export interface ChangePasswordRequest {
     activationCode: string;
     userId?: string;
 }
-export interface MakeFloorPrivateRequest {
-    floorId: string;
-    userId: string;
-    appId: string;
-}
-export interface MakeFloorPublicRequest {
-    floorId: string;
-    userId: string;
-    appId: string;
-}
-export interface RenameFloorRequest {
-    userId: string;
-    appId: string;
-    from: string;
-    to: string;
-}
 export interface ResetPasswordRequest {
     newPassword: string;
     activationCode: string;
@@ -84,27 +68,27 @@ export interface ValidateCodeRequest {
 /**
  *
  */
-export declare class DefaultApi extends runtime.BaseAPI {
+export declare class AuthApi extends runtime.BaseAPI {
     /**
      * Updates the email ID associated with an existing user account after validating a one-time activation code sent to the **new email address**.  This operation can only be performed by a **logged-in user**. When a user initiates an email change, an activation code is sent to the newly provided email ID. The email update takes effect only after the activation code is successfully validated.  If the activation code validation fails, the email ID remains unchanged.  ---  ### **Authentication**  This endpoint requires **Bearer Token authentication**.  ``` Authorization: Bearer <access_token> ```  ---  ### **Request Body**  ```json {   \"user_id\": \"string\",   \"new_email_id\": \"string\",   \"activation_code\": \"string\",   \"app_id\":\"string\" } ```  **Field Description**  * `user_id` – Unique identifier of the logged-in user * `new_email_id` – New email address to be associated with the account * `activation_code` – One-time activation code sent to the new email ID for verification  ---  ### **Flow Summary**  1. User is authenticated and logged in 2. User requests to change email ID 3. System sends an activation code to the **new email address** 4. User submits the activation code via this API 5. On successful validation, the email ID is updated  ---  ### **Successful Response**  On successful validation:  * The activation code is verified * The user’s email ID is updated immediately * A `success` string is returned confirming the email change  ---  ### **Error Response**  The API returns an error response if:  * The activation code is invalid or expired * The activation code does not match the user or email * The new email ID is already in use * Authorization fails or the bearer token is missing or invalid  In all error cases, the existing email ID remains unchanged.  --- ### **Behavior Notes**  * Requires a prior call to `/auth-service/send/validation/code` with the proper mode.  ---  ### **Security Notes (Recommended)**  * Activation codes are single-use and time-bound * Email changes require prior authentication * Rate limiting may be applied to prevent abuse  ---  ### **One-Line Summary**  > Changes a user’s email ID after validating an activation code sent to the new email address.
      * Change email ID
      */
-    changeEmailRaw(requestParameters: ChangeEmailRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<runtime.ApiResponse<SignInWithEmail200Response>>;
+    changeEmailRaw(requestParameters: ChangeEmailRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<runtime.ApiResponse<SignInResponse>>;
     /**
      * Updates the email ID associated with an existing user account after validating a one-time activation code sent to the **new email address**.  This operation can only be performed by a **logged-in user**. When a user initiates an email change, an activation code is sent to the newly provided email ID. The email update takes effect only after the activation code is successfully validated.  If the activation code validation fails, the email ID remains unchanged.  ---  ### **Authentication**  This endpoint requires **Bearer Token authentication**.  ``` Authorization: Bearer <access_token> ```  ---  ### **Request Body**  ```json {   \"user_id\": \"string\",   \"new_email_id\": \"string\",   \"activation_code\": \"string\",   \"app_id\":\"string\" } ```  **Field Description**  * `user_id` – Unique identifier of the logged-in user * `new_email_id` – New email address to be associated with the account * `activation_code` – One-time activation code sent to the new email ID for verification  ---  ### **Flow Summary**  1. User is authenticated and logged in 2. User requests to change email ID 3. System sends an activation code to the **new email address** 4. User submits the activation code via this API 5. On successful validation, the email ID is updated  ---  ### **Successful Response**  On successful validation:  * The activation code is verified * The user’s email ID is updated immediately * A `success` string is returned confirming the email change  ---  ### **Error Response**  The API returns an error response if:  * The activation code is invalid or expired * The activation code does not match the user or email * The new email ID is already in use * Authorization fails or the bearer token is missing or invalid  In all error cases, the existing email ID remains unchanged.  --- ### **Behavior Notes**  * Requires a prior call to `/auth-service/send/validation/code` with the proper mode.  ---  ### **Security Notes (Recommended)**  * Activation codes are single-use and time-bound * Email changes require prior authentication * Rate limiting may be applied to prevent abuse  ---  ### **One-Line Summary**  > Changes a user’s email ID after validating an activation code sent to the new email address.
      * Change email ID
      */
-    changeEmail(requestParameters: ChangeEmailRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<SignInWithEmail200Response>;
+    changeEmail(requestParameters: ChangeEmailRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<SignInResponse>;
     /**
      * Updates the mobile number associated with an existing user account after validating a one-time activation code sent to the **new mobile number**.  This operation can only be performed by a **logged-in user**. When a user initiates a mobile number change, an activation code is sent to the newly provided mobile number. The mobile number update takes effect only after the activation code is successfully validated.  If the activation code validation fails, the mobile number remains unchanged.  ---  ### **Authentication**  This endpoint requires **Bearer Token authentication**.  ``` Authorization: Bearer <access_token> ```  ---  ### **Request Body**  ```json {   \"user_id\": \"string\",   \"new_mobile_number\": \"string\",   \"activation_code\": \"string\" } ```  **Field Description**  * `user_id` – Unique identifier of the logged-in user * `new_mobile_number` – New mobile number to be associated with the account * `activation_code` – One-time activation code sent to the new mobile number for verification  ---  ### **Flow Summary**  1. User is authenticated and logged in 2. User requests to change mobile number 3. System sends an activation code to the **new mobile number** 4. User submits the activation code via this API 5. On successful validation, the mobile number is updated  ---  ### **Successful Response**  On successful validation:  * The activation code is verified * The user’s mobile number is updated immediately * A `success` string is returned confirming the mobile number change  ---  ### **Error Response**  The API returns an error response if:  * The activation code is invalid or expired * The activation code does not match the user or mobile number * The new mobile number is already in use * Authorization fails or the bearer token is missing or invalid  In all error cases, the existing mobile number remains unchanged.  --- ### **Behavior Notes**  * Requires a prior call to `/auth-service/send/validation/code` with the proper mode. ---  ### **Security Notes (Recommended)**  * Activation codes are single-use and time-bound * Mobile number changes require prior authentication * Rate limiting may be applied to prevent abuse  ---  ### **One-Line Summary**  > Changes a user’s mobile number after validating an activation code sent to the new mobile number.
      * Change Mobile number
      */
-    changeMobileNumberRaw(requestParameters: ChangeMobileNumberRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<runtime.ApiResponse<SignInWithEmail200Response>>;
+    changeMobileNumberRaw(requestParameters: ChangeMobileNumberRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<runtime.ApiResponse<SignInResponse>>;
     /**
      * Updates the mobile number associated with an existing user account after validating a one-time activation code sent to the **new mobile number**.  This operation can only be performed by a **logged-in user**. When a user initiates a mobile number change, an activation code is sent to the newly provided mobile number. The mobile number update takes effect only after the activation code is successfully validated.  If the activation code validation fails, the mobile number remains unchanged.  ---  ### **Authentication**  This endpoint requires **Bearer Token authentication**.  ``` Authorization: Bearer <access_token> ```  ---  ### **Request Body**  ```json {   \"user_id\": \"string\",   \"new_mobile_number\": \"string\",   \"activation_code\": \"string\" } ```  **Field Description**  * `user_id` – Unique identifier of the logged-in user * `new_mobile_number` – New mobile number to be associated with the account * `activation_code` – One-time activation code sent to the new mobile number for verification  ---  ### **Flow Summary**  1. User is authenticated and logged in 2. User requests to change mobile number 3. System sends an activation code to the **new mobile number** 4. User submits the activation code via this API 5. On successful validation, the mobile number is updated  ---  ### **Successful Response**  On successful validation:  * The activation code is verified * The user’s mobile number is updated immediately * A `success` string is returned confirming the mobile number change  ---  ### **Error Response**  The API returns an error response if:  * The activation code is invalid or expired * The activation code does not match the user or mobile number * The new mobile number is already in use * Authorization fails or the bearer token is missing or invalid  In all error cases, the existing mobile number remains unchanged.  --- ### **Behavior Notes**  * Requires a prior call to `/auth-service/send/validation/code` with the proper mode. ---  ### **Security Notes (Recommended)**  * Activation codes are single-use and time-bound * Mobile number changes require prior authentication * Rate limiting may be applied to prevent abuse  ---  ### **One-Line Summary**  > Changes a user’s mobile number after validating an activation code sent to the new mobile number.
      * Change Mobile number
      */
-    changeMobileNumber(requestParameters: ChangeMobileNumberRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<SignInWithEmail200Response>;
+    changeMobileNumber(requestParameters: ChangeMobileNumberRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<SignInResponse>;
     /**
      * ## 1) `POST /password/change` — Change Password (Logged-in User)  Changes the password of an **authenticated user** who is currently logged in.  This endpoint is used when a user is already signed in and wants to update their password as a security or preference action. The system validates a **one-time password-change verification code** (`activation_code`) issued specifically for the change-password flow. If the code is valid and not expired, the user’s password is updated to `new_password` and takes effect immediately.  If verification fails, the password remains unchanged and an error response is returned.  ### Authentication  ✅ **Required**: Bearer token for the logged-in session  ``` Authorization: Bearer <access_token> ```  ### Request Body (Form Data)  * `user_id` (optional if derived from token) * `activation_code` (required) * `new_password` (required)  ### Behavior Notes  * Typically requires a prior call to **send a verification code** for password change (mode = password change). * `user_id` can be taken from the access token; include it only if your system requires it explicitly.  ### One-Line Summary  > Changes the password for a logged-in user after validating a one-time password-change code.
      * Change Password
@@ -115,36 +99,6 @@ export declare class DefaultApi extends runtime.BaseAPI {
      * Change Password
      */
     changePassword(requestParameters: ChangePasswordRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<ChangePassword200Response>;
-    /**
-     * This API changes a floor’s visibility to **PRIVATE**.  It is used when a floor owner wants to **restrict access** to a floor that is currently public. After the update, the floor becomes private and is no longer accessible to non-authorized users (based on your platform’s access rules).  This endpoint is **state-changing**:  * If the floor is **PUBLIC**, it will be converted to **PRIVATE** * If the floor is already **PRIVATE**, the API returns success (idempotent) or an “already private” response depending on implementation  This API is commonly used in:  * Floor settings → “Privacy” toggle * Developer-managed pod workflows (app_id context) * Admin tools (if applicable)  ---  ## Request Method  `POST`  ---  ## Content-Type  `application/x-www-form-urlencoded` (or `multipart/form-data` if your system uses form-data) *(Document whichever you actually accept; below assumes standard form fields.)*  ---  ## Request Parameters (Form Fields)  | Field      | Type   | Required | Description                                                          | | ---------- | ------ | -------- | -------------------------------------------------------------------- | | `user_id`  | String | **Yes**  | User requesting the change. Must be the **owner** of the floor.      | | `floor_id` | String | **Yes**  | Public identifier of the floor to update.                            | | `app_id`   | String | No       | Calling application identifier (used for developer/pod integration). |  ---  ## Authorization Rules (Critical)  * The caller must be authenticated as `user_id` * **Only the floor owner** can change floor visibility * If the user is not the owner, the request must be rejected  ---  ## Behavior Rules  * Converts visibility from **PUBLIC → PRIVATE** * Does not modify floor content or blocks * Access enforcement for private floors is applied immediately after the change  **Idempotency**  * Calling this API multiple times should not cause repeated changes * If already private, the API should either:    * return success with a message like `\"already private\"`, or   * return a specific error/status indicating no-op  ---  ## Response Format  `application/json`  ---  ## Sample Success Response  *(Example — adjust to match your actual response format)*  ```json {   \"status\": \"SUCCESS\",   \"floor_id\": \"my_floor\",   \"visibility\": \"PRIVATE\",   \"message\": \"Floor is now private\" } ```  ---  ## Sample No-Op Response (Already Private)  ```json {   \"status\": \"SUCCESS\",   \"floor_id\": \"my_floor\",   \"visibility\": \"PRIVATE\",   \"message\": \"Floor is already private\" } ```  ---  ## Error Responses (Examples)  ### Not Authorized (Not Owner)  ```json {   \"status\": \"ERROR\",   \"message\": \"Only the floor owner can change floor visibility\" } ```  ### Floor Not Found  ```json {   \"status\": \"ERROR\",   \"message\": \"Floor not found\" } ```  ### Invalid Request  ```json {   \"status\": \"ERROR\",   \"message\": \"user_id and floor_id are required\" } ```  ---  ## Notes  * This API is intended to control floor visibility only; membership/invite rules (for private floors) are handled elsewhere. * `app_id` is provided for developer/pod applications and is optional unless enforced by your app model. * If you support floor types like `POD`, document whether pods are allowed to be private or not (some platforms restrict this).
-     * Make floor Private
-     */
-    makeFloorPrivateRaw(requestParameters: MakeFloorPrivateRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<runtime.ApiResponse<GetFloorInformation200Response>>;
-    /**
-     * This API changes a floor’s visibility to **PRIVATE**.  It is used when a floor owner wants to **restrict access** to a floor that is currently public. After the update, the floor becomes private and is no longer accessible to non-authorized users (based on your platform’s access rules).  This endpoint is **state-changing**:  * If the floor is **PUBLIC**, it will be converted to **PRIVATE** * If the floor is already **PRIVATE**, the API returns success (idempotent) or an “already private” response depending on implementation  This API is commonly used in:  * Floor settings → “Privacy” toggle * Developer-managed pod workflows (app_id context) * Admin tools (if applicable)  ---  ## Request Method  `POST`  ---  ## Content-Type  `application/x-www-form-urlencoded` (or `multipart/form-data` if your system uses form-data) *(Document whichever you actually accept; below assumes standard form fields.)*  ---  ## Request Parameters (Form Fields)  | Field      | Type   | Required | Description                                                          | | ---------- | ------ | -------- | -------------------------------------------------------------------- | | `user_id`  | String | **Yes**  | User requesting the change. Must be the **owner** of the floor.      | | `floor_id` | String | **Yes**  | Public identifier of the floor to update.                            | | `app_id`   | String | No       | Calling application identifier (used for developer/pod integration). |  ---  ## Authorization Rules (Critical)  * The caller must be authenticated as `user_id` * **Only the floor owner** can change floor visibility * If the user is not the owner, the request must be rejected  ---  ## Behavior Rules  * Converts visibility from **PUBLIC → PRIVATE** * Does not modify floor content or blocks * Access enforcement for private floors is applied immediately after the change  **Idempotency**  * Calling this API multiple times should not cause repeated changes * If already private, the API should either:    * return success with a message like `\"already private\"`, or   * return a specific error/status indicating no-op  ---  ## Response Format  `application/json`  ---  ## Sample Success Response  *(Example — adjust to match your actual response format)*  ```json {   \"status\": \"SUCCESS\",   \"floor_id\": \"my_floor\",   \"visibility\": \"PRIVATE\",   \"message\": \"Floor is now private\" } ```  ---  ## Sample No-Op Response (Already Private)  ```json {   \"status\": \"SUCCESS\",   \"floor_id\": \"my_floor\",   \"visibility\": \"PRIVATE\",   \"message\": \"Floor is already private\" } ```  ---  ## Error Responses (Examples)  ### Not Authorized (Not Owner)  ```json {   \"status\": \"ERROR\",   \"message\": \"Only the floor owner can change floor visibility\" } ```  ### Floor Not Found  ```json {   \"status\": \"ERROR\",   \"message\": \"Floor not found\" } ```  ### Invalid Request  ```json {   \"status\": \"ERROR\",   \"message\": \"user_id and floor_id are required\" } ```  ---  ## Notes  * This API is intended to control floor visibility only; membership/invite rules (for private floors) are handled elsewhere. * `app_id` is provided for developer/pod applications and is optional unless enforced by your app model. * If you support floor types like `POD`, document whether pods are allowed to be private or not (some platforms restrict this).
-     * Make floor Private
-     */
-    makeFloorPrivate(requestParameters: MakeFloorPrivateRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<GetFloorInformation200Response>;
-    /**
-     * This API changes a floor’s visibility to **PUBLIC**.  It is used when a floor owner wants to **make a private floor accessible to everyone**. After the update, the floor becomes public and can be viewed and discovered by any user, subject to platform rules (search, feeds, pods, etc.).  This endpoint performs a **visibility state transition**:  * **PRIVATE → PUBLIC** * If the floor is already public, the operation is treated as **idempotent** (no state change).  This API is typically used from:  * Floor settings → Privacy / Visibility controls * Owner or admin tools * Developer or pod-based applications using `app_id`  ---  ## Request Method  `POST`  ---  ## Content-Type  `application/x-www-form-urlencoded` (or `multipart/form-data`, depending on your implementation)  ---  ## Request Parameters (Form Fields)  | Field      | Type   | Required | Description                                                                     | | ---------- | ------ | -------- | ------------------------------------------------------------------------------- | | `user_id`  | String | **Yes**  | User requesting the change. Must be the **owner** of the floor.                 | | `floor_id` | String | **Yes**  | Public identifier of the floor whose visibility is to be changed.               | | `app_id`   | String | No       | Identifier of the calling application (used mainly for pod/developer contexts). |  ---  ## Authorization Rules (Critical)  * The caller must be authenticated as `user_id` * **Only the floor owner** is allowed to change the floor’s visibility * Requests from non-owners must be rejected  ---  ## Behavior Rules  * Converts floor visibility from **PRIVATE → PUBLIC** * Does not modify floor content, blocks, or ownership * Visibility change takes effect immediately  ### Idempotency  * If the floor is already public, the API should:    * Return success with a message indicating no change, or   * Return a specific “already public” status (implementation-dependent)  ---  ## Response Format  `application/json`  ---  ## Sample Success Response  ```json {   \"status\": \"SUCCESS\",   \"floor_id\": \"my_floor\",   \"visibility\": \"PUBLIC\",   \"message\": \"Floor is now public\" } ```  ---  ## Sample No-Op Response (Already Public)  ```json {   \"status\": \"SUCCESS\",   \"floor_id\": \"my_floor\",   \"visibility\": \"PUBLIC\",   \"message\": \"Floor is already public\" } ```  ---  ## Error Responses (Examples)  ### Not Authorized (Not Owner)  ```json {   \"status\": \"ERROR\",   \"message\": \"Only the floor owner can change floor visibility\" } ```  ---  ### Floor Not Found  ```json {   \"status\": \"ERROR\",   \"message\": \"Floor not found\" } ```  ---  ### Invalid Request  ```json {   \"status\": \"ERROR\",   \"message\": \"user_id and floor_id are required\" } ```  ---  ## Notes for Developers  * This API controls **visibility only**. Membership, invitations, and moderation rules are handled by separate APIs. * `app_id` is optional and primarily used for developer-managed or pod floors. * Clients should refresh floor metadata (e.g., via `/api/floor/info`) after a successful visibility change.  ---  ### Mental Model (One Line)  > **This API answers: “Make this floor visible to everyone.”**
-     * Make floor public
-     */
-    makeFloorPublicRaw(requestParameters: MakeFloorPublicRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<runtime.ApiResponse<GetFloorInformation200Response>>;
-    /**
-     * This API changes a floor’s visibility to **PUBLIC**.  It is used when a floor owner wants to **make a private floor accessible to everyone**. After the update, the floor becomes public and can be viewed and discovered by any user, subject to platform rules (search, feeds, pods, etc.).  This endpoint performs a **visibility state transition**:  * **PRIVATE → PUBLIC** * If the floor is already public, the operation is treated as **idempotent** (no state change).  This API is typically used from:  * Floor settings → Privacy / Visibility controls * Owner or admin tools * Developer or pod-based applications using `app_id`  ---  ## Request Method  `POST`  ---  ## Content-Type  `application/x-www-form-urlencoded` (or `multipart/form-data`, depending on your implementation)  ---  ## Request Parameters (Form Fields)  | Field      | Type   | Required | Description                                                                     | | ---------- | ------ | -------- | ------------------------------------------------------------------------------- | | `user_id`  | String | **Yes**  | User requesting the change. Must be the **owner** of the floor.                 | | `floor_id` | String | **Yes**  | Public identifier of the floor whose visibility is to be changed.               | | `app_id`   | String | No       | Identifier of the calling application (used mainly for pod/developer contexts). |  ---  ## Authorization Rules (Critical)  * The caller must be authenticated as `user_id` * **Only the floor owner** is allowed to change the floor’s visibility * Requests from non-owners must be rejected  ---  ## Behavior Rules  * Converts floor visibility from **PRIVATE → PUBLIC** * Does not modify floor content, blocks, or ownership * Visibility change takes effect immediately  ### Idempotency  * If the floor is already public, the API should:    * Return success with a message indicating no change, or   * Return a specific “already public” status (implementation-dependent)  ---  ## Response Format  `application/json`  ---  ## Sample Success Response  ```json {   \"status\": \"SUCCESS\",   \"floor_id\": \"my_floor\",   \"visibility\": \"PUBLIC\",   \"message\": \"Floor is now public\" } ```  ---  ## Sample No-Op Response (Already Public)  ```json {   \"status\": \"SUCCESS\",   \"floor_id\": \"my_floor\",   \"visibility\": \"PUBLIC\",   \"message\": \"Floor is already public\" } ```  ---  ## Error Responses (Examples)  ### Not Authorized (Not Owner)  ```json {   \"status\": \"ERROR\",   \"message\": \"Only the floor owner can change floor visibility\" } ```  ---  ### Floor Not Found  ```json {   \"status\": \"ERROR\",   \"message\": \"Floor not found\" } ```  ---  ### Invalid Request  ```json {   \"status\": \"ERROR\",   \"message\": \"user_id and floor_id are required\" } ```  ---  ## Notes for Developers  * This API controls **visibility only**. Membership, invitations, and moderation rules are handled by separate APIs. * `app_id` is optional and primarily used for developer-managed or pod floors. * Clients should refresh floor metadata (e.g., via `/api/floor/info`) after a successful visibility change.  ---  ### Mental Model (One Line)  > **This API answers: “Make this floor visible to everyone.”**
-     * Make floor public
-     */
-    makeFloorPublic(requestParameters: MakeFloorPublicRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<GetFloorInformation200Response>;
-    /**
-     * This API renames a floor by changing knowing the **floor identifier (floor_id)**.  It allows the **floor owner** to update the public-facing floor ID (slug/handle) from an old value to a new value. This is typically used when the owner wants to rebrand, reorganize, or correct the floor’s identifier.  ⚠️ **This operation affects how the floor is accessed and referenced externally**, so it must be performed carefully.  ---  ## Ownership & Authorization (Critical)  * The caller **must be authenticated** * **Only the floor owner** is allowed to rename a floor * Members, followers, or non-owners **cannot** perform this operation * Ownership is validated internally using `user_id`  > If the user is not the owner, the request must be rejected.  ---  ## Request Method  `POST`  ---  ## Content-Type  `application/x-www-form-urlencoded` (or equivalent form-data encoding)  ---  ## Request Parameters (Form Fields)  | Parameter | Type   | Required | Description                                                                     | | --------- | ------ | -------- | ------------------------------------------------------------------------------- | | `user_id` | String | **Yes**  | User requesting the rename. Must be the **owner** of the floor.                 | | `from`    | String | **Yes**  | Existing floor ID (current identifier to be renamed).                           | | `to`      | String | **Yes**  | New floor ID to assign to the floor.                                            | | `app_id`  | String | No       | Identifier of the calling application (used mainly for pod/developer contexts). |  ---  ## Rename Rules & Constraints  * The `from` floor ID **must exist** * The `to` floor ID **must be unique** and not already in use * The rename operation updates **only the floor ID**    * Floor ownership, blocks, posts, and internal `fid` remain unchanged * Any links or references using the old floor ID may no longer be valid after rename  ---  ## Behavior Summary  | Scenario                     | Result                                            | | ---------------------------- | ------------------------------------------------- | | Valid owner + unique new ID  | Floor ID renamed successfully                     | | Non-owner user               | Request rejected                                  | | `from` floor ID not found    | Error                                             | | `to` floor ID already exists | Error                                             | | `from` == `to`               | No-op or validation error (implementation choice) |  ---  ## Response Format  `application/json`  ---  ## Sample Success Response  ```json {   \"status\": \"SUCCESS\",   \"old_floor_id\": \"oldfloorid\",   \"new_floor_id\": \"newfloorid\",   \"message\": \"Floor ID renamed successfully\" } ```  ---  ## Sample Error Responses  ### Not Floor Owner  ```json {   \"status\": \"ERROR\",   \"message\": \"Only the floor owner can rename the floor\" } ```  ---  ### Floor Not Found  ```json {   \"status\": \"ERROR\",   \"message\": \"Source floor ID does not exist\" } ```  ---  ### Floor ID Already Exists  ```json {   \"status\": \"ERROR\",   \"message\": \"Target floor ID is already in use\" } ```  ---  ### Invalid Request  ```json {   \"status\": \"ERROR\",   \"message\": \"user_id, from, and to are required\" } ```  ---  ## Notes for Developers  * This API **renames the public identifier only**; the internal immutable floor ID (`fid`) is not affected. * Clients should refresh cached floor metadata after a successful rename. * If your platform supports deep links or bookmarks, consider redirect or alias handling for old floor IDs (if supported).  ---  ### One-Line Mental Model  > **This API answers: “Change the public identity (ID) of a floor, owner-only.”**
-     * Rename floor
-     */
-    renameFloorRaw(requestParameters: RenameFloorRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<runtime.ApiResponse<GetFloorInformation200Response>>;
-    /**
-     * This API renames a floor by changing knowing the **floor identifier (floor_id)**.  It allows the **floor owner** to update the public-facing floor ID (slug/handle) from an old value to a new value. This is typically used when the owner wants to rebrand, reorganize, or correct the floor’s identifier.  ⚠️ **This operation affects how the floor is accessed and referenced externally**, so it must be performed carefully.  ---  ## Ownership & Authorization (Critical)  * The caller **must be authenticated** * **Only the floor owner** is allowed to rename a floor * Members, followers, or non-owners **cannot** perform this operation * Ownership is validated internally using `user_id`  > If the user is not the owner, the request must be rejected.  ---  ## Request Method  `POST`  ---  ## Content-Type  `application/x-www-form-urlencoded` (or equivalent form-data encoding)  ---  ## Request Parameters (Form Fields)  | Parameter | Type   | Required | Description                                                                     | | --------- | ------ | -------- | ------------------------------------------------------------------------------- | | `user_id` | String | **Yes**  | User requesting the rename. Must be the **owner** of the floor.                 | | `from`    | String | **Yes**  | Existing floor ID (current identifier to be renamed).                           | | `to`      | String | **Yes**  | New floor ID to assign to the floor.                                            | | `app_id`  | String | No       | Identifier of the calling application (used mainly for pod/developer contexts). |  ---  ## Rename Rules & Constraints  * The `from` floor ID **must exist** * The `to` floor ID **must be unique** and not already in use * The rename operation updates **only the floor ID**    * Floor ownership, blocks, posts, and internal `fid` remain unchanged * Any links or references using the old floor ID may no longer be valid after rename  ---  ## Behavior Summary  | Scenario                     | Result                                            | | ---------------------------- | ------------------------------------------------- | | Valid owner + unique new ID  | Floor ID renamed successfully                     | | Non-owner user               | Request rejected                                  | | `from` floor ID not found    | Error                                             | | `to` floor ID already exists | Error                                             | | `from` == `to`               | No-op or validation error (implementation choice) |  ---  ## Response Format  `application/json`  ---  ## Sample Success Response  ```json {   \"status\": \"SUCCESS\",   \"old_floor_id\": \"oldfloorid\",   \"new_floor_id\": \"newfloorid\",   \"message\": \"Floor ID renamed successfully\" } ```  ---  ## Sample Error Responses  ### Not Floor Owner  ```json {   \"status\": \"ERROR\",   \"message\": \"Only the floor owner can rename the floor\" } ```  ---  ### Floor Not Found  ```json {   \"status\": \"ERROR\",   \"message\": \"Source floor ID does not exist\" } ```  ---  ### Floor ID Already Exists  ```json {   \"status\": \"ERROR\",   \"message\": \"Target floor ID is already in use\" } ```  ---  ### Invalid Request  ```json {   \"status\": \"ERROR\",   \"message\": \"user_id, from, and to are required\" } ```  ---  ## Notes for Developers  * This API **renames the public identifier only**; the internal immutable floor ID (`fid`) is not affected. * Clients should refresh cached floor metadata after a successful rename. * If your platform supports deep links or bookmarks, consider redirect or alias handling for old floor IDs (if supported).  ---  ### One-Line Mental Model  > **This API answers: “Change the public identity (ID) of a floor, owner-only.”**
-     * Rename floor
-     */
-    renameFloor(requestParameters: RenameFloorRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<GetFloorInformation200Response>;
     /**
      * ---  ## Reset Password (Forgot Password, Not Logged In)  Resets the password of a user who **cannot log in** and is using a **forgot-password** flow.  This endpoint is used when the user is not authenticated and requests a password reset using a verified identity channel such as **email** or **mobile number**. The system validates a **one-time reset verification code** (`activation_code`) issued for the reset-password flow. If valid and not expired, the password is updated to `new_password` and takes effect immediately.  If verification fails, the password remains unchanged and an error response is returned.  ### Authentication  ✅ **Recommended** (better security): a short-lived **reset token** issued after initiating reset  ``` Authorization: Bearer <reset_token> ```  > If you don’t use a reset token, you must enforce strong rate limiting + OTP attempt throttling on this endpoint.  ### Request Body (Form Data)  * `email_id` or `mobile_number` (required to identify user) * `activation_code` (required) * `new_password` (required) * `user_id` (optional, if your reset flow already resolved it)  ### Behavior Notes  * Requires a prior call to **initiate reset** and send OTP/code (mode = forgot password). * Must enforce code attempt limits and expiration strictly.  ### One-Line Summary  > Resets a user’s password (forgot-password flow) after validating a one-time reset code sent to email or mobile.
      * Reset Password
@@ -169,22 +123,22 @@ export declare class DefaultApi extends runtime.BaseAPI {
      * Authenticates a user using a registered email ID. The authentication mechanism is determined by the specified `mode`.  * When `login_type` is set to **`1`**, the user is authenticated using the provided **password**. * When `login_type` is set to **`2`**, the user is authenticated using a **one-time activation code (OTP)**.  For OTP-based authentication (`login_type = 2`), the client **must first invoke the Send Validation Code API** with the appropriate login mode to generate and deliver the activation code to the user.  --- ### **Request Body**  | Field        | Type          | Required | Description                                                       | | ------------ | ------------- | -------- | ----------------------------------------------------------------- | | `email_id` | string | Yes      | Email ID | | `pass_code` | string | Yes      | Password/Validation code depending on the login_type| | `login_type` | string | Yes      | login type 1 for password 2 for validation code|   |`app_id` | string | Yes      | App ID |     **Field Description**  * `email_id` – Registered email address of the user * `pass_code` – password or activation code  (this is password if it is 1 and 2 it is validation code) * `app_id` - App ID which is a 13 digit numeric value * `login_type` – Login type   * `1` → Password-based login   * `2` → Activation code (OTP)–based login  ---  ### **Behavior Notes**  * When `login_type = 2`, password validation is bypassed. * OTP-based login requires a prior call to ` /auth-service/send/sign/in/validation/code`. * If the required credentials for the selected mode are missing or invalid, authentication fails.  ---  ### **Successful Response**  On successful authentication, the user is signed in and a success response is returned as per the authentication flow.  ---  ### **Error Response**  The API returns an error response if:  * The email ID is not registered * The password is incorrect (`login_type = 1 `) * The activation code is missing, invalid, or expired (`login_type = 2`) * The mode value is invalid or unsupported  ---  ### **One-Line Summary**  > Signs in a user using an email ID with either password-based or OTP-based authentication, based on the selected mode.
      * Sign In with email ID
      */
-    signInWithEmailRaw(requestParameters: SignInWithEmailRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<runtime.ApiResponse<SignInWithEmail200Response>>;
+    signInWithEmailRaw(requestParameters: SignInWithEmailRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<runtime.ApiResponse<SignInResponse>>;
     /**
      * Authenticates a user using a registered email ID. The authentication mechanism is determined by the specified `mode`.  * When `login_type` is set to **`1`**, the user is authenticated using the provided **password**. * When `login_type` is set to **`2`**, the user is authenticated using a **one-time activation code (OTP)**.  For OTP-based authentication (`login_type = 2`), the client **must first invoke the Send Validation Code API** with the appropriate login mode to generate and deliver the activation code to the user.  --- ### **Request Body**  | Field        | Type          | Required | Description                                                       | | ------------ | ------------- | -------- | ----------------------------------------------------------------- | | `email_id` | string | Yes      | Email ID | | `pass_code` | string | Yes      | Password/Validation code depending on the login_type| | `login_type` | string | Yes      | login type 1 for password 2 for validation code|   |`app_id` | string | Yes      | App ID |     **Field Description**  * `email_id` – Registered email address of the user * `pass_code` – password or activation code  (this is password if it is 1 and 2 it is validation code) * `app_id` - App ID which is a 13 digit numeric value * `login_type` – Login type   * `1` → Password-based login   * `2` → Activation code (OTP)–based login  ---  ### **Behavior Notes**  * When `login_type = 2`, password validation is bypassed. * OTP-based login requires a prior call to ` /auth-service/send/sign/in/validation/code`. * If the required credentials for the selected mode are missing or invalid, authentication fails.  ---  ### **Successful Response**  On successful authentication, the user is signed in and a success response is returned as per the authentication flow.  ---  ### **Error Response**  The API returns an error response if:  * The email ID is not registered * The password is incorrect (`login_type = 1 `) * The activation code is missing, invalid, or expired (`login_type = 2`) * The mode value is invalid or unsupported  ---  ### **One-Line Summary**  > Signs in a user using an email ID with either password-based or OTP-based authentication, based on the selected mode.
      * Sign In with email ID
      */
-    signInWithEmail(requestParameters: SignInWithEmailRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<SignInWithEmail200Response>;
+    signInWithEmail(requestParameters: SignInWithEmailRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<SignInResponse>;
     /**
      * Authenticates a user using a registered mobile number. The authentication method is determined by the specified `mode`.  * When `login_type` is set to **`1`**, the user is authenticated using the **password** associated with the account. * When `login_type` is set to **`2`**, the user is authenticated using a **one-time activation code (OTP)** sent to the registered mobile number.  For OTP-based authentication (`login_type = 1`), the client **must first call the Send Validation Code API** with the appropriate login mode to generate and deliver the activation code.  ---  ### **Request Formdata**  | Field        | Type          | Required | Description                                                       | | ------------ | ------------- | -------- | ----------------------------------------------------------------- | | `mobile_number` | string | Yes      | Mobile number| | `pass_code` | string | Yes      | Password/Validation code depending on the login_type| | `login_type` | string | Yes      | login type 1 for password 2 for validation code|   |`app_id` | string | Yes      | App ID |    **Field Description**  * `mobile_number` – Registered mobile number of the user * `pass_code` – Password / Validation code (password when `login_type= 1`; validation code when `login_type = 2`) * `login_type` – Login type    * `1` → Password-based login   * `2` → Activation code (OTP)–based login  ---  ### **Behavior Notes**  * When `login_type = 2`, password validation is skipped. * OTP-based login requires a prior call to `/auth-service/send/sign/in/validation/code`. * Missing or invalid credentials for the selected mode will result in authentication failure.  ---  ### **Successful Response**  On successful authentication, the user is signed in and a success response is returned according to the authentication flow.  ---  ### **Error Response**  The API returns an error response if:  * The mobile number is not registered * The password is incorrect (`login_type = 1`) * The activation code is missing, invalid, or expired (`login_type = 2`) * An invalid or unsupported mode is provided  ---  ### **One-Line Summary**  > Signs in a user using a mobile number with either password-based or OTP-based authentication, based on the selected mode.
      * Sign In with Mobile number
      */
-    signInWithMobileNumberRaw(requestParameters: SignInWithMobileNumberRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<runtime.ApiResponse<SignInWithEmail200Response>>;
+    signInWithMobileNumberRaw(requestParameters: SignInWithMobileNumberRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<runtime.ApiResponse<SignInResponse>>;
     /**
      * Authenticates a user using a registered mobile number. The authentication method is determined by the specified `mode`.  * When `login_type` is set to **`1`**, the user is authenticated using the **password** associated with the account. * When `login_type` is set to **`2`**, the user is authenticated using a **one-time activation code (OTP)** sent to the registered mobile number.  For OTP-based authentication (`login_type = 1`), the client **must first call the Send Validation Code API** with the appropriate login mode to generate and deliver the activation code.  ---  ### **Request Formdata**  | Field        | Type          | Required | Description                                                       | | ------------ | ------------- | -------- | ----------------------------------------------------------------- | | `mobile_number` | string | Yes      | Mobile number| | `pass_code` | string | Yes      | Password/Validation code depending on the login_type| | `login_type` | string | Yes      | login type 1 for password 2 for validation code|   |`app_id` | string | Yes      | App ID |    **Field Description**  * `mobile_number` – Registered mobile number of the user * `pass_code` – Password / Validation code (password when `login_type= 1`; validation code when `login_type = 2`) * `login_type` – Login type    * `1` → Password-based login   * `2` → Activation code (OTP)–based login  ---  ### **Behavior Notes**  * When `login_type = 2`, password validation is skipped. * OTP-based login requires a prior call to `/auth-service/send/sign/in/validation/code`. * Missing or invalid credentials for the selected mode will result in authentication failure.  ---  ### **Successful Response**  On successful authentication, the user is signed in and a success response is returned according to the authentication flow.  ---  ### **Error Response**  The API returns an error response if:  * The mobile number is not registered * The password is incorrect (`login_type = 1`) * The activation code is missing, invalid, or expired (`login_type = 2`) * An invalid or unsupported mode is provided  ---  ### **One-Line Summary**  > Signs in a user using a mobile number with either password-based or OTP-based authentication, based on the selected mode.
      * Sign In with Mobile number
      */
-    signInWithMobileNumber(requestParameters: SignInWithMobileNumberRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<SignInWithEmail200Response>;
+    signInWithMobileNumber(requestParameters: SignInWithMobileNumberRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<SignInResponse>;
     /**
      * Creates a new user account in the Floor POD using **either a mobile number or an email ID**. At least **one of `mobile_number` or `email_id` is required** to register a user. Both may be provided if available.  The API registers the user under the specified application context and prepares the account for subsequent authentication and usage.  Upon successful registration, the API returns: - a unique user_id identifying the newly created user, and - a success string indicating the outcome of the sign-up operation. The user account is created under the specified application context and can be used for subsequent interactions with Floor POD APIs.  ---  ### **Parameter Clarification (Recommended)**  * `name` is mandatory for user profile creation * Either `mobile_number` **or** `email_id` must be present * `app_id` is optional and used to associate the user with a specific application
      * Sign Up