@brokerize/client 1.3.8 → 1.3.10

package/dist/client.d.ts

@@ -1075,29 +1075,28 @@ declare function AuthMethodTanToJSONRecursive(value?: AuthMethodTan | null, igno
 declare function AuthMethodToJSON(value?: AuthMethod | null): any;
 
 export declare class AuthorizedApiContext {
-    private _cfg;
-    private _auth;
-    private _defaultApi;
-    private _demoBrokerApi;
-    private _tradeApi;
-    private _tradeApiCryptoService;
     private _isDestroyed;
-    private _abortController;
-    private _metaApi;
-    private _brokerLoginApi;
-    private _tradeDraftApi;
-    private _cancelOrderApi;
-    private _cancelOrderApiCryptoService;
-    private _changeOrderApi;
-    private _changeOrderApiCryptoService;
-    private _logoutSubject;
     private _childContexts;
-    private _wsClient;
-    private _cache;
-    private _exportApi;
-    private _adminApi;
-    private _userApi;
-    private _securitiesApi;
+    private readonly _cfg;
+    private readonly _auth;
+    private readonly _demoBrokerApi;
+    private readonly _tradeApi;
+    private readonly _tradeApiCryptoService;
+    private readonly _abortController;
+    private readonly _metaApi;
+    private readonly _sessionApi;
+    private readonly _tradeDraftApi;
+    private readonly _orderApi;
+    private readonly _orderApiCryptoService;
+    private readonly _logoutSubject;
+    private readonly _wsClient;
+    private readonly _cache;
+    private readonly _exportApi;
+    private readonly _adminApi;
+    private readonly _userApi;
+    private readonly _securitiesApi;
+    private readonly _portfolioApi;
+    private readonly _decoupledOperationsApi;
     constructor(cfg: BrokerizeConfig, auth: Auth, wsClient?: BrokerizeWebSocketClient);
     createChildContext(): AuthorizedApiContext;
     private _initRequestInit;
@@ -1142,7 +1141,7 @@ export declare class AuthorizedApiContext {
     cancelDecoupledOperation(req: openApiClient.CancelDecoupledOperationRequest): Promise<void>;
     triggerSessionSync(sessionId: string): Promise<openApiClient.OkResponseBody>;
     triggerDemoSessionSyncError(sessionId: string): Promise<openApiClient.OkResponseBody>;
-    logoutSession(sessionId: string): Promise<openApiClient.OkResponseBody>;
+    logoutSession(sessionId: string): Promise<openApiClient.LogoutOkResponseBody>;
     getUser(): Promise<openApiClient.GetUserResponse>;
     deleteGuestUser(): Promise<void>;
     prepareTrade(req: PrepareTradeRequest): Promise<openApiClient.PrepareTradeResponse>;
@@ -1437,7 +1436,7 @@ declare function BrokerEnvironmentToJSONRecursive(value?: BrokerEnvironment | nu
 
 export declare class Brokerize {
     private _cfg;
-    private _defaultApi;
+    private _userApi;
     constructor(cfg: BrokerizeConfig);
     refreshGuestUser(refreshToken: string): Promise<GuestAuthContextConfiguration>;
     createGuestUser(): Promise<AuthContextConfiguration>;
@@ -1550,42 +1549,6 @@ declare type BrokerizeWebSocketError = {
     message: string;
 };
 
-/**
- *
- */
-declare class BrokerLoginApi extends runtime.BaseAPI {
-    /**
-     */
-    addSessionRaw(requestParameters: AddSessionRequest, initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<runtime.ApiResponse<LoginResponse>>;
-    /**
-     */
-    addSession(requestParameters: AddSessionRequest, initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<LoginResponse>;
-    /**
-     * If login returns the state `challenge`, the login must be completed by providing a challenge response first.
-     */
-    addSessionCompleteChallengeRaw(requestParameters: AddSessionCompleteChallengeRequest, initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<runtime.ApiResponse<LoginResponseReady>>;
-    /**
-     * If login returns the state `challenge`, the login must be completed by providing a challenge response first.
-     */
-    addSessionCompleteChallenge(requestParameters: AddSessionCompleteChallengeRequest, initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<LoginResponseReady>;
-    /**
-     * For brokers with OAuth login processes, this adds the session to the user\'s account after redirects happen. Only the user that is redirected from the broker login in the browser will receive the `code`. This step ensures that the logged-in user at brokerize is actually the one that has gone through the broker OAuth steps.
-     */
-    confirmOAuthRaw(requestParameters: ConfirmOAuthRequest, initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<runtime.ApiResponse<ConfirmOAuthResponse>>;
-    /**
-     * For brokers with OAuth login processes, this adds the session to the user\'s account after redirects happen. Only the user that is redirected from the broker login in the browser will receive the `code`. This step ensures that the logged-in user at brokerize is actually the one that has gone through the broker OAuth steps.
-     */
-    confirmOAuth(requestParameters: ConfirmOAuthRequest, initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<ConfirmOAuthResponse>;
-    /**
-     * For brokers with `isOAuth`, sessions can not be created using `AddSession`. This is how a session can be added for an OAuth-based login process:  1. use `prepareOAuthRedirect` to obtain a URL to redirect to. You can provide a `returnTo` URL which will be redirected to later. Note that a list of allowed URLs has to be configured for the client. 2. redirect the user\'s browser to the `redirectTo` URL 3. after the user has logged in at the broker\'s interface, a redirect to `returnTo` with the URL query parameters `verifysession=1`, `code` and `ticketId` will happen 4. the `returnTo` page must call `confirmOAuth` with the given `ticketId` and `code` to finally add the session to the user\'s account
-     */
-    prepareOAuthRedirectRaw(requestParameters: PrepareOAuthRedirectRequest, initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<runtime.ApiResponse<PrepareOAuthRedirectResponse>>;
-    /**
-     * For brokers with `isOAuth`, sessions can not be created using `AddSession`. This is how a session can be added for an OAuth-based login process:  1. use `prepareOAuthRedirect` to obtain a URL to redirect to. You can provide a `returnTo` URL which will be redirected to later. Note that a list of allowed URLs has to be configured for the client. 2. redirect the user\'s browser to the `redirectTo` URL 3. after the user has logged in at the broker\'s interface, a redirect to `returnTo` with the URL query parameters `verifysession=1`, `code` and `ticketId` will happen 4. the `returnTo` page must call `confirmOAuth` with the given `ticketId` and `code` to finally add the session to the user\'s account
-     */
-    prepareOAuthRedirect(requestParameters: PrepareOAuthRedirectRequest, initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<PrepareOAuthRedirectResponse>;
-}
-
 /**
  * If a login form can be shown for the broker, describes the fields to show.
  * @export
@@ -1835,28 +1798,6 @@ declare interface CancelDecoupledOperationRequest {
     decoupledOperationId: string;
 }
 
-/**
- *
- */
-declare class CancelOrderApi extends runtime.BaseAPI {
-    /**
-     * Cancel the given order (or in the case of decoupled authMethods: send the order cancellation to the user for confirmation. In this case, a decoupledOperationId is returned).
-     */
-    cancelOrderRaw(requestParameters: CancelOrderRequest, initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<runtime.ApiResponse<CancelOrderResponse>>;
-    /**
-     * Cancel the given order (or in the case of decoupled authMethods: send the order cancellation to the user for confirmation. In this case, a decoupledOperationId is returned).
-     */
-    cancelOrder(requestParameters: CancelOrderRequest, initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<CancelOrderResponse>;
-    /**
-     * If the user chose an auth method from `GetAuthInfo` with the flow `CHALLENGE_RESPONSE`, before cancelling an order, a challenge must be requested first. If any other flow is used, a challenge *must not* be requested and `CancelOrder` is used right away.
-     */
-    createCancelOrderChallengeRaw(requestParameters: CreateCancelOrderChallengeRequest, initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<runtime.ApiResponse<Challenge>>;
-    /**
-     * If the user chose an auth method from `GetAuthInfo` with the flow `CHALLENGE_RESPONSE`, before cancelling an order, a challenge must be requested first. If any other flow is used, a challenge *must not* be requested and `CancelOrder` is used right away.
-     */
-    createCancelOrderChallenge(requestParameters: CreateCancelOrderChallengeRequest, initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<Challenge>;
-}
-
 /**
  * brokerize
  * The brokerize API allows clients to implement multi-brokerage with a unified interface. For more information, visit brokerize.com
@@ -2430,36 +2371,6 @@ declare function ChallengeToJSON(value?: Challenge | null): any;
 
 declare function ChallengeToJSONRecursive(value?: Challenge | null, ignoreParent?: boolean): any;
 
-/**
- *
- */
-declare class ChangeOrderApi extends runtime.BaseAPI {
-    /**
-     * Perform an order change.
-     */
-    changeOrderRaw(requestParameters: ChangeOrderRequest, initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<runtime.ApiResponse<ChangeOrderResponse>>;
-    /**
-     * Perform an order change.
-     */
-    changeOrder(requestParameters: ChangeOrderRequest, initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<ChangeOrderResponse>;
-    /**
-     * If the user chose an auth method from `GetAuthInfo` with the flow `CHALLENGE_RESPONSE`, before changing an order, a challenge must be requested first. If any other flow is used, a challenge *must not* be requested and `ChangeOrder` is used right away.
-     */
-    createChangeOrderChallengeRaw(requestParameters: CreateChangeOrderChallengeRequest, initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<runtime.ApiResponse<Challenge>>;
-    /**
-     * If the user chose an auth method from `GetAuthInfo` with the flow `CHALLENGE_RESPONSE`, before changing an order, a challenge must be requested first. If any other flow is used, a challenge *must not* be requested and `ChangeOrder` is used right away.
-     */
-    createChangeOrderChallenge(requestParameters: CreateChangeOrderChallengeRequest, initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<Challenge>;
-    /**
-     * Get an order cost estimation for an order change.
-     */
-    getChangeOrderCostEstimationRaw(requestParameters: GetChangeOrderCostEstimationRequest, initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<runtime.ApiResponse<OrderCostEstimation>>;
-    /**
-     * Get an order cost estimation for an order change.
-     */
-    getChangeOrderCostEstimation(requestParameters: GetChangeOrderCostEstimationRequest, initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<OrderCostEstimation>;
-}
-
 /**
  *
  * @export
@@ -2573,6 +2484,42 @@ declare function ChangeOrderResponseToJSON(value?: ChangeOrderResponse | null):
 
 declare function ChangeOrderResponseToJSONRecursive(value?: ChangeOrderResponse | null, ignoreParent?: boolean): any;
 
+/**
+ * brokerize
+ * The brokerize API allows clients to implement multi-brokerage with a unified interface. For more information, visit brokerize.com
+ *
+ *
+ *
+ * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
+ * https://openapi-generator.tech
+ * Do not edit the class manually.
+ */
+/**
+ *
+ * @export
+ * @interface CheckRecoveryPhrase200Response
+ */
+declare interface CheckRecoveryPhrase200Response {
+    /**
+     *
+     * @type {Date}
+     * @memberof CheckRecoveryPhrase200Response
+     */
+    expiresAt: Date;
+}
+
+declare function CheckRecoveryPhrase200ResponseFromJSON(json: any): CheckRecoveryPhrase200Response;
+
+declare function CheckRecoveryPhrase200ResponseFromJSONTyped(json: any, ignoreDiscriminator: boolean): CheckRecoveryPhrase200Response;
+
+declare function CheckRecoveryPhrase200ResponseToJSON(value?: CheckRecoveryPhrase200Response | null): any;
+
+declare function CheckRecoveryPhrase200ResponseToJSONRecursive(value?: CheckRecoveryPhrase200Response | null, ignoreParent?: boolean): any;
+
+declare interface CheckRecoveryPhraseRequest {
+    obtainTokenByRecoveryPhraseParams: ObtainTokenByRecoveryPhraseParams;
+}
+
 /**
  * The client configuration as it appears in API endpoints.
  * @export
@@ -3807,6 +3754,75 @@ declare function CreateOrderParamsToJSON(value?: CreateOrderParams | null): any;
 
 declare function CreateOrderParamsToJSONRecursive(value?: CreateOrderParams | null, ignoreParent?: boolean): any;
 
+/**
+ * brokerize
+ * The brokerize API allows clients to implement multi-brokerage with a unified interface. For more information, visit brokerize.com
+ *
+ *
+ *
+ * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
+ * https://openapi-generator.tech
+ * Do not edit the class manually.
+ */
+/**
+ *
+ * @export
+ * @interface CreateRecoveryPhraseParams
+ */
+declare interface CreateRecoveryPhraseParams {
+    /**
+     * A name for the RecoveryPhrase. Must be unique for the user so that they can identify it in the list
+     * of RecoveryPhrases.
+     * @type {string}
+     * @memberof CreateRecoveryPhraseParams
+     */
+    name: string;
+}
+
+declare function CreateRecoveryPhraseParamsFromJSON(json: any): CreateRecoveryPhraseParams;
+
+declare function CreateRecoveryPhraseParamsFromJSONTyped(json: any, ignoreDiscriminator: boolean): CreateRecoveryPhraseParams;
+
+declare function CreateRecoveryPhraseParamsToJSON(value?: CreateRecoveryPhraseParams | null): any;
+
+declare function CreateRecoveryPhraseParamsToJSONRecursive(value?: CreateRecoveryPhraseParams | null, ignoreParent?: boolean): any;
+
+declare interface CreateRecoveryPhraseRequest {
+    createRecoveryPhraseParams: CreateRecoveryPhraseParams;
+}
+
+/**
+ * brokerize
+ * The brokerize API allows clients to implement multi-brokerage with a unified interface. For more information, visit brokerize.com
+ *
+ *
+ *
+ * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
+ * https://openapi-generator.tech
+ * Do not edit the class manually.
+ */
+/**
+ *
+ * @export
+ * @interface CreateRecoveryPhraseResult
+ */
+declare interface CreateRecoveryPhraseResult {
+    /**
+     *
+     * @type {string}
+     * @memberof CreateRecoveryPhraseResult
+     */
+    recoveryPhrase: string;
+}
+
+declare function CreateRecoveryPhraseResultFromJSON(json: any): CreateRecoveryPhraseResult;
+
+declare function CreateRecoveryPhraseResultFromJSONTyped(json: any, ignoreDiscriminator: boolean): CreateRecoveryPhraseResult;
+
+declare function CreateRecoveryPhraseResultToJSON(value?: CreateRecoveryPhraseResult | null): any;
+
+declare function CreateRecoveryPhraseResultToJSONRecursive(value?: CreateRecoveryPhraseResult | null, ignoreParent?: boolean): any;
+
 declare interface CreateSessionTanChallengeRequest {
     sessionId: string;
     createTanChallengeParams: CreateTanChallengeParams;
@@ -3932,6 +3948,24 @@ declare interface DeactivateTradeDraftRequest {
     id: string;
 }
 
+/**
+ *
+ */
+declare class DecoupledOperationsApi extends runtime.BaseAPI {
+    /**
+     */
+    cancelDecoupledOperationRaw(requestParameters: CancelDecoupledOperationRequest, initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<runtime.ApiResponse<void>>;
+    /**
+     */
+    cancelDecoupledOperation(requestParameters: CancelDecoupledOperationRequest, initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<void>;
+    /**
+     */
+    getDecoupledOperationStatusRaw(requestParameters: GetDecoupledOperationStatusRequest, initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<runtime.ApiResponse<DecoupledOperationStatus>>;
+    /**
+     */
+    getDecoupledOperationStatus(requestParameters: GetDecoupledOperationStatusRequest, initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<DecoupledOperationStatus>;
+}
+
 /**
  *
  * @export
@@ -4019,208 +4053,6 @@ declare function DecoupledOperationStatusToJSON(value?: DecoupledOperationStatus
 
 declare function DecoupledOperationStatusToJSONRecursive(value?: DecoupledOperationStatus | null, ignoreParent?: boolean): any;
 
-/**
- *
- */
-declare class DefaultApi extends runtime.BaseAPI {
-    /**
-     */
-    cancelDecoupledOperationRaw(requestParameters: CancelDecoupledOperationRequest, initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<runtime.ApiResponse<void>>;
-    /**
-     */
-    cancelDecoupledOperation(requestParameters: CancelDecoupledOperationRequest, initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<void>;
-    /**
-     * Cancel a decoupled operation.  This is deprecated, use the new `CancelDecoupledOperation` instead (which does not require the sessionId anymore).
-     */
-    cancelDecoupledOperationLegacyRaw(requestParameters: CancelDecoupledOperationLegacyRequest, initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<runtime.ApiResponse<void>>;
-    /**
-     * Cancel a decoupled operation.  This is deprecated, use the new `CancelDecoupledOperation` instead (which does not require the sessionId anymore).
-     */
-    cancelDecoupledOperationLegacy(requestParameters: CancelDecoupledOperationLegacyRequest, initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<void>;
-    /**
-     * Create a guest user and return a token which can be used to access resources.  The lifetime of the generated temporary user as well as the returned `access_token` depend on the client configuration. It is usually around 24 hours. For some clients, tokens can be expired earlier based on inactivity.  If the client has configured a longer lifetime for their guest users, a `refresh_token`  is included in the response. This token can be used to renew the `access_token` after it has expired.  The `refresh_token` can be used to obtain a new `access_token` after the original token has expired using the `/user/token` endpoint.
-     */
-    createGuestUserRaw(initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<runtime.ApiResponse<CreateGuestUserResponse>>;
-    /**
-     * Create a guest user and return a token which can be used to access resources.  The lifetime of the generated temporary user as well as the returned `access_token` depend on the client configuration. It is usually around 24 hours. For some clients, tokens can be expired earlier based on inactivity.  If the client has configured a longer lifetime for their guest users, a `refresh_token`  is included in the response. This token can be used to renew the `access_token` after it has expired.  The `refresh_token` can be used to obtain a new `access_token` after the original token has expired using the `/user/token` endpoint.
-     */
-    createGuestUser(initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<CreateGuestUserResponse>;
-    /**
-     * If the user chose an auth method from `GetAuthInfo` with the flow `CHALLENGE_RESPONSE`, before enabling session TAN, a challenge must be requested first.
-     */
-    createSessionTanChallengeRaw(requestParameters: CreateSessionTanChallengeRequest, initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<runtime.ApiResponse<Challenge>>;
-    /**
-     * If the user chose an auth method from `GetAuthInfo` with the flow `CHALLENGE_RESPONSE`, before enabling session TAN, a challenge must be requested first.
-     */
-    createSessionTanChallenge(requestParameters: CreateSessionTanChallengeRequest, initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<Challenge>;
-    /**
-     * Delete the current user (only allowed if it is a guest account). Also logs out all active broker sessions attached to the user.
-     */
-    deleteGuestUserRaw(initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<runtime.ApiResponse<void>>;
-    /**
-     * Delete the current user (only allowed if it is a guest account). Also logs out all active broker sessions attached to the user.
-     */
-    deleteGuestUser(initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<void>;
-    /**
-     */
-    deletePortfolioRaw(requestParameters: DeletePortfolioRequest, initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<runtime.ApiResponse<OkResponseBody>>;
-    /**
-     */
-    deletePortfolio(requestParameters: DeletePortfolioRequest, initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<OkResponseBody>;
-    /**
-     */
-    enableSessionTanRaw(requestParameters: EnableSessionTanRequest, initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<runtime.ApiResponse<EnableSessionTanResponse>>;
-    /**
-     */
-    enableSessionTan(requestParameters: EnableSessionTanRequest, initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<EnableSessionTanResponse>;
-    /**
-     * End Session TAN for the given broker session.  If applicable, the broker may return a message with a confirmation code which can be looked up in the initial activation SMS. If message is present in the response, it should be displayed to the user.
-     */
-    endSessionTanRaw(requestParameters: EndSessionTanRequest, initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<runtime.ApiResponse<EndSessionTanResponse>>;
-    /**
-     * End Session TAN for the given broker session.  If applicable, the broker may return a message with a confirmation code which can be looked up in the initial activation SMS. If message is present in the response, it should be displayed to the user.
-     */
-    endSessionTan(requestParameters: EndSessionTanRequest, initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<EndSessionTanResponse>;
-    /**
-     * Get the AuthInfo for the given portfolio.  If the portfolio does not have an online session, this will return a 400 status code.  If it does, the response describes whether session TAN is available or active and which auth methods are available for the given portfolio (this information depends on the broker and the user\'s account settings).  The response determines which of the following operations can be used and which are required to successfully perform an operation in a portfolio:  -   Session TAN handling (for performing other actions in portfolios without further per-case authorization)     -   [CreateSessionTanChallenge](#operation/CreateSessionTanChallenge) to request a challenge for s TAN activation.     -   [EnableSessionTan](#operation/EnableSessionTan) to enable the session TAN.     -   [EndSessionTan](#operation/EndSessionTan) to end the session TAN. -   Create a trade     -   [PrepareTrade](#operation/PrepareTrade) to figure out how a given security can be traded in a portfolio.     -   [CreateTradeChallenge](#operation/CreateTradeChallenge) to (for example) request a TAN for a trade.     -   [CreateTrade](#operation/CreateTrade) to perform the trade. -   Edit an order     -   [CreateChangeOrderChallenge](#operation/CreateChangeOrderChallenge) to request a challenge for an order change.     -   [ChangeOrder](#operation/ChangeOrder) to change an order. -   Cancel an order     -   [CreateCancelOrderChallenge](#operation/CreateCancelOrderChallenge) to request a Challenge for an order cancellation.     -   [CancelOrder](#operation/CancelOrder) to cancel an order.  The list of available AuthMethods should only be presented to the user if session TAN is not active (yet). The list and names are defined by our partner brokers. All auth methods are generally categorized using the `flow` attribute:  | `flow`               | requires challenge? | Description                                                                                                                                                                                                          | | -------------------- | ------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `TAN`                | no                  | the simplest flow: no challenge is required to perform the operation. the TAN is simply sent as parameter `tan`                                                                              | | `CHALLENGE_RESPONSE` | yes                 | a challenge must be created using the `createXYZChallenge` operations and the challenge must be presented to the user. The user can then execute the action using the `challengeId` and `challengeResponse` parameters. If the auth method has `challengeResponseIsOnlyConfirmation=true`, that challengeResponse is always an empty string and users do not enter a TAN. Otherwise, a text field labelled with `tanFieldLabel` must be displayed where the user enteirs their challengeResponse. | | `DECOUPLED`          | no                  | the operation is executed without any TAN, but returns a `decoupledOperationId` which can be used to read the action\'s status. Users will authorize the action in another frontend (usually in their broker\'s app). Note that currently `DECOUPLED` auth methods only work for enabling session TAN.   |  - If `sessionTanActive` is `true`: Session TAN has been enabled for the session that currently backs the portfolio. In this case, all operations like `CreateTrade` can be executed right away without an `authMethod`. The UI should *not* show a dropdown with the auth methods in this case. - If `sessionTanActive` is `false` but `sessionTanSupported` is `true`: the user can enable session TAN using `CreateSessionTanChallenge` / `EnableSessionTan`. - If `allOperationsRequireSessionTan` is `true`, the auth methods can *ONLY* be used for enabling session TAN. - Otherwise, the `authMethods` can be used to perform individual operations.  | sessionTanActive | sessionTanSupported | allOperationsRequireSessionTan | Description                                                                                                                                                                                                                                                 | | ---------------- | ------------------- | ------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `true`           | `true`              | -                              | Session TAN has been enabled for the session that currently backs the portfolio. In this case, all operations like `CreateTrade`, `ChangeOrder`, `CancelOrder` can be executed right away without an `authMethod`. The UI should _not_ show a dropdown with the auth methods in this case. | | `false`          | `true`              | `true`                         | the user can enable session TAN using the provided auth methods via `CreateSessionTanChallenge` / `EnableSessionTan`. All other operations can only take place after session TAN has been enabled.                                                          | | `false`          | `true`              | `false`                        | the user can enable any operation (enable session tan, create trade, cancel order, change order) using the provided auth methods                                                                                                                            |  Note that it is possible that brokers only reveal all details about the available auth methods *TOGETHER* with the first `GetChallenge` request. This special behavior can be simulated with our demo broker when the flag `lazyAuthMethods=true` is specified upon creation of a demo account. In those accounts, the `GetAuthInfo` endpoint will initially return a single \"placeholder\" method with `{flow: \"CHALLENGE_RESPONSE\", isDefaultMethod: true, ...}`.  In the situation where there is *exactly one* auth method like this, frontends may immediately request the challenge for the desired operation without waiting for the user to click the get challenge button (for Session TAN, this means that as soon as the user opens the dialog for enabling session TAN, `CreateSessionTanChallenge` can be called). In the case described here, `AuthInfo` will be populated with the actual list of auth methods when the create challenge request returns (also, the corresponding WebSocket event is published to notify about this change). `GetAuthInfo` must be called again in this case and repopulate the corresponding frontend (e.g. the name of the auth method will become available etc.). So what is done in this case is: request a challenge for the *unknown* default method in order to get both a challenge and an update of the auth methods.  Note that usually challenges have effects like an SMS or some broker app notification for the end user, so it is important to keep the requested challenge info, *even when auth info is refreshed*. For example, if there is a select box with the auth method list, that box must keep its selected `id` while updating the now-available `label`. This way, the user can use the first requested challenge, as the frontend will still be in the right state.
-     */
-    getAuthInfoRaw(requestParameters: GetAuthInfoRequest, initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<runtime.ApiResponse<GetAuthInfoResponse>>;
-    /**
-     * Get the AuthInfo for the given portfolio.  If the portfolio does not have an online session, this will return a 400 status code.  If it does, the response describes whether session TAN is available or active and which auth methods are available for the given portfolio (this information depends on the broker and the user\'s account settings).  The response determines which of the following operations can be used and which are required to successfully perform an operation in a portfolio:  -   Session TAN handling (for performing other actions in portfolios without further per-case authorization)     -   [CreateSessionTanChallenge](#operation/CreateSessionTanChallenge) to request a challenge for s TAN activation.     -   [EnableSessionTan](#operation/EnableSessionTan) to enable the session TAN.     -   [EndSessionTan](#operation/EndSessionTan) to end the session TAN. -   Create a trade     -   [PrepareTrade](#operation/PrepareTrade) to figure out how a given security can be traded in a portfolio.     -   [CreateTradeChallenge](#operation/CreateTradeChallenge) to (for example) request a TAN for a trade.     -   [CreateTrade](#operation/CreateTrade) to perform the trade. -   Edit an order     -   [CreateChangeOrderChallenge](#operation/CreateChangeOrderChallenge) to request a challenge for an order change.     -   [ChangeOrder](#operation/ChangeOrder) to change an order. -   Cancel an order     -   [CreateCancelOrderChallenge](#operation/CreateCancelOrderChallenge) to request a Challenge for an order cancellation.     -   [CancelOrder](#operation/CancelOrder) to cancel an order.  The list of available AuthMethods should only be presented to the user if session TAN is not active (yet). The list and names are defined by our partner brokers. All auth methods are generally categorized using the `flow` attribute:  | `flow`               | requires challenge? | Description                                                                                                                                                                                                          | | -------------------- | ------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `TAN`                | no                  | the simplest flow: no challenge is required to perform the operation. the TAN is simply sent as parameter `tan`                                                                              | | `CHALLENGE_RESPONSE` | yes                 | a challenge must be created using the `createXYZChallenge` operations and the challenge must be presented to the user. The user can then execute the action using the `challengeId` and `challengeResponse` parameters. If the auth method has `challengeResponseIsOnlyConfirmation=true`, that challengeResponse is always an empty string and users do not enter a TAN. Otherwise, a text field labelled with `tanFieldLabel` must be displayed where the user enteirs their challengeResponse. | | `DECOUPLED`          | no                  | the operation is executed without any TAN, but returns a `decoupledOperationId` which can be used to read the action\'s status. Users will authorize the action in another frontend (usually in their broker\'s app). Note that currently `DECOUPLED` auth methods only work for enabling session TAN.   |  - If `sessionTanActive` is `true`: Session TAN has been enabled for the session that currently backs the portfolio. In this case, all operations like `CreateTrade` can be executed right away without an `authMethod`. The UI should *not* show a dropdown with the auth methods in this case. - If `sessionTanActive` is `false` but `sessionTanSupported` is `true`: the user can enable session TAN using `CreateSessionTanChallenge` / `EnableSessionTan`. - If `allOperationsRequireSessionTan` is `true`, the auth methods can *ONLY* be used for enabling session TAN. - Otherwise, the `authMethods` can be used to perform individual operations.  | sessionTanActive | sessionTanSupported | allOperationsRequireSessionTan | Description                                                                                                                                                                                                                                                 | | ---------------- | ------------------- | ------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `true`           | `true`              | -                              | Session TAN has been enabled for the session that currently backs the portfolio. In this case, all operations like `CreateTrade`, `ChangeOrder`, `CancelOrder` can be executed right away without an `authMethod`. The UI should _not_ show a dropdown with the auth methods in this case. | | `false`          | `true`              | `true`                         | the user can enable session TAN using the provided auth methods via `CreateSessionTanChallenge` / `EnableSessionTan`. All other operations can only take place after session TAN has been enabled.                                                          | | `false`          | `true`              | `false`                        | the user can enable any operation (enable session tan, create trade, cancel order, change order) using the provided auth methods                                                                                                                            |  Note that it is possible that brokers only reveal all details about the available auth methods *TOGETHER* with the first `GetChallenge` request. This special behavior can be simulated with our demo broker when the flag `lazyAuthMethods=true` is specified upon creation of a demo account. In those accounts, the `GetAuthInfo` endpoint will initially return a single \"placeholder\" method with `{flow: \"CHALLENGE_RESPONSE\", isDefaultMethod: true, ...}`.  In the situation where there is *exactly one* auth method like this, frontends may immediately request the challenge for the desired operation without waiting for the user to click the get challenge button (for Session TAN, this means that as soon as the user opens the dialog for enabling session TAN, `CreateSessionTanChallenge` can be called). In the case described here, `AuthInfo` will be populated with the actual list of auth methods when the create challenge request returns (also, the corresponding WebSocket event is published to notify about this change). `GetAuthInfo` must be called again in this case and repopulate the corresponding frontend (e.g. the name of the auth method will become available etc.). So what is done in this case is: request a challenge for the *unknown* default method in order to get both a challenge and an update of the auth methods.  Note that usually challenges have effects like an SMS or some broker app notification for the end user, so it is important to keep the requested challenge info, *even when auth info is refreshed*. For example, if there is a select box with the auth method list, that box must keep its selected `id` while updating the now-available `label`. This way, the user can use the first requested challenge, as the frontend will still be in the right state.
-     */
-    getAuthInfo(requestParameters: GetAuthInfoRequest, initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<GetAuthInfoResponse>;
-    /**
-     */
-    getDecoupledOperationStatusRaw(requestParameters: GetDecoupledOperationStatusRequest, initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<runtime.ApiResponse<DecoupledOperationStatus>>;
-    /**
-     */
-    getDecoupledOperationStatus(requestParameters: GetDecoupledOperationStatusRequest, initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<DecoupledOperationStatus>;
-    /**
-     * Get the status of a decoupled operation.  This is deprecated, use the new `GetDecoupledOperation` instead, which does not require the `sessionId` any more.
-     */
-    getDecoupledOperationStatusLegacyRaw(requestParameters: GetDecoupledOperationStatusLegacyRequest, initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<runtime.ApiResponse<DecoupledOperationStatus>>;
-    /**
-     * Get the status of a decoupled operation.  This is deprecated, use the new `GetDecoupledOperation` instead, which does not require the `sessionId` any more.
-     */
-    getDecoupledOperationStatusLegacy(requestParameters: GetDecoupledOperationStatusLegacyRequest, initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<DecoupledOperationStatus>;
-    /**
-     */
-    getOrderRaw(requestParameters: GetOrderRequest, initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<runtime.ApiResponse<GetOrderResponse>>;
-    /**
-     */
-    getOrder(requestParameters: GetOrderRequest, initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<GetOrderResponse>;
-    /**
-     * Retrieve \"by-day\" aggregated values for the selected date ranges.
-     */
-    getPortfolioCalendarRaw(requestParameters: GetPortfolioCalendarRequest, initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<runtime.ApiResponse<GetPortfolioCalendarResponse>>;
-    /**
-     * Retrieve \"by-day\" aggregated values for the selected date ranges.
-     */
-    getPortfolioCalendar(requestParameters: GetPortfolioCalendarRequest, initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<GetPortfolioCalendarResponse>;
-    /**
-     */
-    getPortfolioOrdersRaw(requestParameters: GetPortfolioOrdersRequest, initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<runtime.ApiResponse<GetPortfolioOrdersResponse>>;
-    /**
-     */
-    getPortfolioOrders(requestParameters: GetPortfolioOrdersRequest, initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<GetPortfolioOrdersResponse>;
-    /**
-     */
-    getPortfolioPositionsRaw(requestParameters: GetPortfolioPositionsRequest, initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<runtime.ApiResponse<GetPortfolioPositionsResponse>>;
-    /**
-     */
-    getPortfolioPositions(requestParameters: GetPortfolioPositionsRequest, initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<GetPortfolioPositionsResponse>;
-    /**
-     */
-    getPortfolioQuotesRaw(requestParameters: GetPortfolioQuotesRequest, initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<runtime.ApiResponse<GetPortfolioQuotesResponse>>;
-    /**
-     */
-    getPortfolioQuotes(requestParameters: GetPortfolioQuotesRequest, initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<GetPortfolioQuotesResponse>;
-    /**
-     * Load statistics based on the trade list for selected date ranges. The statistics (such as `longestWinningStreak` or `tradeCount`) are computed for each of the requested date ranges.
-     */
-    getPortfolioTradeStatisticsRaw(requestParameters: GetPortfolioTradeStatisticsRequest, initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<runtime.ApiResponse<GetPortfolioTradeStatisticsResponse>>;
-    /**
-     * Load statistics based on the trade list for selected date ranges. The statistics (such as `longestWinningStreak` or `tradeCount`) are computed for each of the requested date ranges.
-     */
-    getPortfolioTradeStatistics(requestParameters: GetPortfolioTradeStatisticsRequest, initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<GetPortfolioTradeStatisticsResponse>;
-    /**
-     */
-    getPortfolioTradeWarningsRaw(requestParameters: GetPortfolioTradeWarningsRequest, initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<runtime.ApiResponse<Array<TradeWarning>>>;
-    /**
-     */
-    getPortfolioTradeWarnings(requestParameters: GetPortfolioTradeWarningsRequest, initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<Array<TradeWarning>>;
-    /**
-     * Load a list of completed trades in a portfolio. A completed trade corresponds to *one* closing of a position. Technically each closing of a position corresponds to one execution of an order with `intent=close` (usually those are sell orders, but in the case of short selling, opening a position is a sell order with intent=open).  The analysis follows the FIFO (First In, First Out) principle to accurately summarize trades. Each time a position is closed (note that partial executions are possible. In this case, each individual execution is regarded as a transaction), the system identifies the earliest corresponding \"open position execution\" that contributed to that closing. The result includes a single entry for each closing transaction, detailing key metrics such as profit/loss and holding period, based on the matched opening transactions.  This could be a real world example: - 2020-01-01: buy 5 stock1 for 100 USD each - 2021-06-01: buy 3 stock1 for 200 USD each - 2021-06-06: sell 6 stock1 for 300 USD each  In this case, the result would be one completed trade (corresponding to the last sell) with a profit of `(300*6)-(100*5+1*200)=1800-700=1100 USD`. There is an open position remaining (2 units of stock1, which correspond to the second buy transaction).  When we add this sell: - 2021-06-07: sell 2 stock1 for 400 USD each  It would add a second complete trade with a profit of `(400*2)-(200*2)=800-400=400 USD`.  For some brokers, the order history may be incomplete (e.g. only reveals the latest 90 days), so that we do not know if there could be older transactions. Thus, our implementation might detect (given the current set of open positions together with the list of order executions) that we cannot figure out the corresponding opening transactions for a closing transaction. Affected trades will be ignored for this analysis and might appear as warning items in the `/warnings` endpoint. Frontends should show those warnings so that users can understand why the analysis is incomplete.
-     */
-    getPortfolioTradesRaw(requestParameters: GetPortfolioTradesRequest, initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<runtime.ApiResponse<GetPortfolioTradesResponse>>;
-    /**
-     * Load a list of completed trades in a portfolio. A completed trade corresponds to *one* closing of a position. Technically each closing of a position corresponds to one execution of an order with `intent=close` (usually those are sell orders, but in the case of short selling, opening a position is a sell order with intent=open).  The analysis follows the FIFO (First In, First Out) principle to accurately summarize trades. Each time a position is closed (note that partial executions are possible. In this case, each individual execution is regarded as a transaction), the system identifies the earliest corresponding \"open position execution\" that contributed to that closing. The result includes a single entry for each closing transaction, detailing key metrics such as profit/loss and holding period, based on the matched opening transactions.  This could be a real world example: - 2020-01-01: buy 5 stock1 for 100 USD each - 2021-06-01: buy 3 stock1 for 200 USD each - 2021-06-06: sell 6 stock1 for 300 USD each  In this case, the result would be one completed trade (corresponding to the last sell) with a profit of `(300*6)-(100*5+1*200)=1800-700=1100 USD`. There is an open position remaining (2 units of stock1, which correspond to the second buy transaction).  When we add this sell: - 2021-06-07: sell 2 stock1 for 400 USD each  It would add a second complete trade with a profit of `(400*2)-(200*2)=800-400=400 USD`.  For some brokers, the order history may be incomplete (e.g. only reveals the latest 90 days), so that we do not know if there could be older transactions. Thus, our implementation might detect (given the current set of open positions together with the list of order executions) that we cannot figure out the corresponding opening transactions for a closing transaction. Affected trades will be ignored for this analysis and might appear as warning items in the `/warnings` endpoint. Frontends should show those warnings so that users can understand why the analysis is incomplete.
-     */
-    getPortfolioTrades(requestParameters: GetPortfolioTradesRequest, initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<GetPortfolioTradesResponse>;
-    /**
-     */
-    getPortfoliosRaw(initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<runtime.ApiResponse<PortfoliosResponse>>;
-    /**
-     */
-    getPortfolios(initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<PortfoliosResponse>;
-    /**
-     * Get the currently active broker sessions of the user\'s account.
-     */
-    getSessionsRaw(initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<runtime.ApiResponse<SessionResponse>>;
-    /**
-     * Get the currently active broker sessions of the user\'s account.
-     */
-    getSessions(initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<SessionResponse>;
-    /**
-     * Checks the provided authentication and returns the logged-in user.
-     */
-    getUserRaw(initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<runtime.ApiResponse<GetUserResponse>>;
-    /**
-     * Checks the provided authentication and returns the logged-in user.
-     */
-    getUser(initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<GetUserResponse>;
-    /**
-     * Log out from the given broker session.
-     */
-    logoutSessionRaw(requestParameters: LogoutSessionRequest, initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<runtime.ApiResponse<OkResponseBody>>;
-    /**
-     * Log out from the given broker session.
-     */
-    logoutSession(requestParameters: LogoutSessionRequest, initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<OkResponseBody>;
-    /**
-     * Obtain a new access token using a refresh token as specified in https://datatracker.ietf.org/doc/html/rfc6749#section-4.1.4. If `CreateGuestUser` has provided a `refresh_token`, this endpoint may be used to obtain a new `access_token` after the original token has expired.
-     */
-    obtainTokenRaw(requestParameters: ObtainTokenRequest, initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<runtime.ApiResponse<TokenResponse>>;
-    /**
-     * Obtain a new access token using a refresh token as specified in https://datatracker.ietf.org/doc/html/rfc6749#section-4.1.4. If `CreateGuestUser` has provided a `refresh_token`, this endpoint may be used to obtain a new `access_token` after the original token has expired.
-     */
-    obtainToken(requestParameters: ObtainTokenRequest, initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<TokenResponse>;
-    /**
-     * This endpoint can be used to rename the display name of a specified portfolio. To restore the original portfolio name, send a rename request with an empty string as the new name. **Note**: This does not change the original portfolio name at your broker.
-     */
-    renamePortfolioRaw(requestParameters: RenamePortfolioOperationRequest, initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<runtime.ApiResponse<void>>;
-    /**
-     * This endpoint can be used to rename the display name of a specified portfolio. To restore the original portfolio name, send a rename request with an empty string as the new name. **Note**: This does not change the original portfolio name at your broker.
-     */
-    renamePortfolio(requestParameters: RenamePortfolioOperationRequest, initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<void>;
-    /**
-     * Trigger a background sync process for the given broker session. This means that a sync will be scheduled as soon as possible. All data related to the portfolio (e.g. positions and orders) will be loaded into the brokerize database.
-     */
-    triggerSessionSyncRaw(requestParameters: TriggerSessionSyncRequest, initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<runtime.ApiResponse<OkResponseBody>>;
-    /**
-     * Trigger a background sync process for the given broker session. This means that a sync will be scheduled as soon as possible. All data related to the portfolio (e.g. positions and orders) will be loaded into the brokerize database.
-     */
-    triggerSessionSync(requestParameters: TriggerSessionSyncRequest, initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<OkResponseBody>;
-    /**
-     * Most operations at brokerize have asynchronous effects.  For example, consider the flow of an order: when the user creates an order, it will not immediately appear in order list endpoints, because usually brokers take a few seconds until they are retrievable in those lists. Also, after a while, the order may be executed or cancelled asynchronously by the stock exchange.  A common solution for frontends would be to reload the order list regularly. However data is then either delayed or there will be many more requests than needed.  The brokerize websocket endpoint allows getting updates via web sockets. Generally speaking, clients can subscribe by assigning a subscription id and will then receive updates on that subscription.  In this documentation, ⬆️ denotes messages from the client to the server, whereas messages from server to client are marked with ⬇️.  ## authentication  When using cookies for authorization, the WebSocket connection is authenticated with the HTTP upgrade request.  If token headers are used, the _first_ message from client to server must be:  ``` ⬆️ {     \"cmd\": \"authorize\",     \"idToken\": <string> } ```  In all cases, clients must wait for the welcome message before sending other messages:  ``` ⬇️ { \"cmd\": \"authenticated\" } ```  ## ping  After 1 minute of inactivity of a client, the WebSocket connection will be considered stale and will automatically terminated. To prevent this, a ping message can be sent:  ```  ⬆️ {\"cmd\": \"ping\"} ```  The server also sends this message regularly. If no message has been received on a WebSocket connection for more than 1 minute, it should be terminated by the client.  ```  ⬇️ {\"cmd\": \"ping\"} ```  ## subscriptions  Subscriptions can be used to get invalidate events or updates for selected resources.  ### invalidate subscriptions  Invalidation events can be used for the frontend to know when reload requests via the HTTP endpoints are appropriate. Currently only invalidate events can be subscribed, the actual data must then be reloaded using the HTTP endpoints.  To set up a subscription for an invalidate event, use:  ``` ⬆️ {     \"cmd\": \"subscribe\",     \"type\": \"invalidate\",     \"subscriptionId\": 1,     \"entity: \"brokersessions\" /_* \"positions\" | \"orders\" *_/,     \"portfolioId\": 42 /_* required for \"positions\" or \"orders\" *_/ } ```  If the subscription failed to be set up on the server, an error will be sent for the subscription. This also automatically ends the subscription on the server side:  ``` ⬇️ {     \"subscriptionId\": 1,     \"error\": {         \"message\": \"Could not set up invalidation event due to...\"     } } ```  If an invalid `subscriptionId` is provided (or the subscription id is already in use by the connection), an error like this will be sent:  ``` ⬇️ {     \"error\": {         \"message\": \"Could not add subscription due to invalid subscriptionId\"     } } ```  ⚠️ _the connection will then be terminated immediately_.  If the subscription is sucessfuly set up, whenever an invalidation happens, the server will send a message like this:  ``` ⬇️ {     \"cmd\": \"invalidate\",     \"subscriptionId\": 1 } ```  When that invalidation event is received, the client should reload the data using the corresponding endpoints.  Clients can end their subscription with the `unsubscribe` command:  ``` ⬆️ {     \"cmd\": \"unsubscribe\",     \"subscriptionId\": 1 } ```  ### subscribe to the state of a decoupled operation  For decoupled operations (e.g. authorizing a session TAN using a second factor device), the state of the operation can be subscribed:  ``` ⬆️ {     \"cmd\": \"subscribe\",     \"type\": \"decoupledOperationStatus\",     \"subscriptionId\": 1,     \"sessionId\": string,     \"decoupledOperationId\": string } ```  Error handling as well as unsubscribing works as described for invalidate subscriptions. Example message from the server for updating the state:  ``` ⬇️ {     \"cmd\": \"updateDecoupledOperationStatus\",     \"subscriptionId\": number,     \"state\": <DecoupledOperationStatus> } ```
-     */
-    websocketRaw(initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<runtime.ApiResponse<void>>;
-    /**
-     * Most operations at brokerize have asynchronous effects.  For example, consider the flow of an order: when the user creates an order, it will not immediately appear in order list endpoints, because usually brokers take a few seconds until they are retrievable in those lists. Also, after a while, the order may be executed or cancelled asynchronously by the stock exchange.  A common solution for frontends would be to reload the order list regularly. However data is then either delayed or there will be many more requests than needed.  The brokerize websocket endpoint allows getting updates via web sockets. Generally speaking, clients can subscribe by assigning a subscription id and will then receive updates on that subscription.  In this documentation, ⬆️ denotes messages from the client to the server, whereas messages from server to client are marked with ⬇️.  ## authentication  When using cookies for authorization, the WebSocket connection is authenticated with the HTTP upgrade request.  If token headers are used, the _first_ message from client to server must be:  ``` ⬆️ {     \"cmd\": \"authorize\",     \"idToken\": <string> } ```  In all cases, clients must wait for the welcome message before sending other messages:  ``` ⬇️ { \"cmd\": \"authenticated\" } ```  ## ping  After 1 minute of inactivity of a client, the WebSocket connection will be considered stale and will automatically terminated. To prevent this, a ping message can be sent:  ```  ⬆️ {\"cmd\": \"ping\"} ```  The server also sends this message regularly. If no message has been received on a WebSocket connection for more than 1 minute, it should be terminated by the client.  ```  ⬇️ {\"cmd\": \"ping\"} ```  ## subscriptions  Subscriptions can be used to get invalidate events or updates for selected resources.  ### invalidate subscriptions  Invalidation events can be used for the frontend to know when reload requests via the HTTP endpoints are appropriate. Currently only invalidate events can be subscribed, the actual data must then be reloaded using the HTTP endpoints.  To set up a subscription for an invalidate event, use:  ``` ⬆️ {     \"cmd\": \"subscribe\",     \"type\": \"invalidate\",     \"subscriptionId\": 1,     \"entity: \"brokersessions\" /_* \"positions\" | \"orders\" *_/,     \"portfolioId\": 42 /_* required for \"positions\" or \"orders\" *_/ } ```  If the subscription failed to be set up on the server, an error will be sent for the subscription. This also automatically ends the subscription on the server side:  ``` ⬇️ {     \"subscriptionId\": 1,     \"error\": {         \"message\": \"Could not set up invalidation event due to...\"     } } ```  If an invalid `subscriptionId` is provided (or the subscription id is already in use by the connection), an error like this will be sent:  ``` ⬇️ {     \"error\": {         \"message\": \"Could not add subscription due to invalid subscriptionId\"     } } ```  ⚠️ _the connection will then be terminated immediately_.  If the subscription is sucessfuly set up, whenever an invalidation happens, the server will send a message like this:  ``` ⬇️ {     \"cmd\": \"invalidate\",     \"subscriptionId\": 1 } ```  When that invalidation event is received, the client should reload the data using the corresponding endpoints.  Clients can end their subscription with the `unsubscribe` command:  ``` ⬆️ {     \"cmd\": \"unsubscribe\",     \"subscriptionId\": 1 } ```  ### subscribe to the state of a decoupled operation  For decoupled operations (e.g. authorizing a session TAN using a second factor device), the state of the operation can be subscribed:  ``` ⬆️ {     \"cmd\": \"subscribe\",     \"type\": \"decoupledOperationStatus\",     \"subscriptionId\": 1,     \"sessionId\": string,     \"decoupledOperationId\": string } ```  Error handling as well as unsubscribing works as described for invalidate subscriptions. Example message from the server for updating the state:  ``` ⬇️ {     \"cmd\": \"updateDecoupledOperationStatus\",     \"subscriptionId\": number,     \"state\": <DecoupledOperationStatus> } ```
-     */
-    websocket(initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<void>;
-}
-
 declare const DefaultConfig: Configuration;
 
 /**
@@ -4323,6 +4155,10 @@ declare interface DeletePortfolioRequest {
     portfolioId: string;
 }
 
+declare interface DeleteRecoveryPhraseRequest {
+    recoveryPhraseId: string;
+}
+
 declare interface DeleteTradeDraftRequest {
     id: string;
 }
@@ -4454,11 +4290,11 @@ declare function DemoAccountToJSONRecursive(value?: DemoAccount | null, ignorePa
  */
 declare class DemobrokerApi extends runtime.BaseAPI {
     /**
-     * Create an account at the demo broker for the logged-in user. The account will have a default set of two empty portfolios by default. If the setting `isSinglePortfolio` is set, only one portfolio is created.  The account as well as the two portfolios have a randomly generated name.  To log into an account, use the account\'s generated name as username (Account name) in `AddSession`. - with the password `42`, the login will succeed immediately - with the password `1337`, a challenge with type text will be returned which must be completed by using `addSessionCompleteChallenge` (with a challengeResponse `42`) - with the password `7`, a challenge with type base64png will be returned which must be completed by using `addSessionCompleteChallenge` (with a challengeResponse `42`) - other passwords will not allow to log in  The demo broker implements the following pre-defined trade behaviors, so that different flows can be tested: - ISIN US0378331005 (Apple):   - market buy order is executed after 10 seconds by the backend at a random quote   - stop buy or stop loss order stays open forever (can be used for testing cancellation)   - cost estimations contain a `costDetailsLink` and a `costAcceptancePrompt`   - securityDetailedInfo is set, so a \"KID\" link should be displayed and linked to the corresponding table   - the preparedTrade\'s `costEstimationMustBeShown` is true, so that the correct behavior (users cannot skip cost estimation in that case) can be tested. - ISIN LU0378438732 (a DAX ETF)   - preparedTrade has `costEstimationIsOnlyDetailedTable` set to true, so that deviating order form behaviors can be tested   - orders are rejected with code `ORDER_REJECTED` immediately - ISIN LU2611732046 (a DAX ETF)   - preparedTrade has `costEstimationIsOnlyDetailedTable` set to true, so that deviating order form behaviors can be tested   - two exchanges are available (\"xetra\" and \"quoteExchange\")   - xetra allows market and limit orders for buying and has defaultValidityByOrderModel set to GFD for market and GTD 2030-01-01 for limit   - orders are rejected with code `ORDER_REJECTED` immediately - ISIN DE000MD96WE8 (a knock out with DAX as underlying)   - prepareTrade is rejected with a message that the user may not trade risky derivatives. - ISIN DE000DTR0CK8 (Daimler Truck Holding)   - prepareTrade is rejected with a message that the user may not trade risky derivatives. - ISIN US4180561072 (Hasbro)   - only quote orders on one exchange are supported   - the quotes are valid for 45 seconds   - quote value is always `42`   - the order gets executed immediately - ISIN DE0005557508 (Deutsche Telekom)   - only quote orders on two different exchanges are supported   - the quotes do *NOT* have an expiration   - quote value is always `42`   - quote comes together with a costEstimation. Subsequent getCostEstimation calls are not allowed.   - `noExchangeDefault` is true, so that exchange must be selected by the user   - order will be canceled after 3 seconds - ISIN US98980L1017 (Zoom)   - only market orders (both buy and sell) are suppored on one exchange   - orders are executed immediately at a random quote   - order creation requires the user to accept a hint (i.e. first try will result in a `MUST_ACCEPT_HINT` error)   - default validity is set to `GTD` with a date of `2030-01-01` - ISIN US29786A1060 (Etsy)   - the prepareTrade request takes 5 seconds   - create challenge takes 5 seconds. for authMethod photoTAN, the challenge will return with an error after that period of time   - only quote and market orders allowed   - at exchange \"Slow exchange\" it takes 7 seconds to get a quote as well as 7 seconds to retrieve order costs   - at exchange \"Exchange with quote and cost errors\" the quote request as well as cost estimation will end with an error after 3 seconds   - the preparedTrade\'s `costEstimationMustBeShown` is true, so that the correct behavior (users cannot skip cost estimation in that case) can be tested. - ISIN XS2149280948 (bond from Bertelsmann)   - quote, limit and market orders (both buy and sell) are supported on one exchange   - limit orders are executed at exactly the limit price   - market orders are executed at a random quote between 90 and 150 percent   - for market orders, there is a legal message to confirm set (`legalMessagesToConfirmByOrderModel`) - ISIN US64110L1061 (Netflix Inc.)   - one exchange with only quote order   - creating the quote order will return an error (quote expired)  - ISIN US67066G1040 (NVIDIA)    - one exchange with only quote order, allowsQuoteModeLimit=true    - quote orders are executed immediately.      - if a quoteLimit is provided, execution happen at quoteLimit value      - otherwise, a random execution quote will be used - ISIN DE000BAY0017 (Bayer AG)   - one exchange with only market order   - `costEstimationIsNotAvailable` is true, so no cost estimations should be linked/shown   - orders will be canceled after 3 seconds - ISIN DE000PAH0038 (Porsche)   - one exchange with only market order   - all orders will be canceled   - `GetCostEstimation` contains (only) a link to a PDF document. This can be used to test whether linking to a PDF works.   - the instrument has both a `riskClassInfo.legalHint` as well as a `strikingHint`. Both should be visible in the order form. - ISIN DE0008404005 (Allianz) and some other hidden ISINs (can be requested from brokerize support)   - one exchange with all available orderModels   - orders are executed immediately   - limit orders are executed at exactly the provided limit price - ISIN DE0008430026 (Munich Re)   - one exchange (L&S) with all available orderModels   - orders are executed immediately - ISIN FR0000120321 (L\'Oréal)   - one exchange with all available orderModels   - the exchange has a `securityQuotesToken` set   - orders stay open   - changesHaveCostEstimations is `true` for orders with this ISIN - ISIN US5949181045 (Microsoft)   - one exchange with all available orderModels   - if size is even, a partial execution with size 1 is executed, the remaining part stays open   - if size is odd, a partial execution with size 1 is executed, the remaining part is canceled - ISIN US30303M1027 (Meta)   - one exchange with all available orderModels   - for each piece of the order size, there will be one execution with size 1 (so e.g. 10 executions for size 10)   - sizes > 30 are not accepted - ISIN US2546871060 (Disney)   - one exchange with all available orderModels   - all orders are canceled after 3s   - `costEstimationMustBeShown` is false and `costEstimationIsOnlyDetailedTable` is true (frontends must only show a link to the cost estimation table) - ISIN XX1234567890 (example of an ISIN that can never be mapped by frontends)   - one exchange with all available orderModels   - the instrument has two sellPositions to choose from (\"Sell Position A\" and \"Sell Position B\"). If no correct sell position is provided, trades will be rejected.   - orders are executed immediately - ISIN DE0007100000 (Mercedes-Benz)   - one exchange with all available orderModels   - the instrument has two sellPositions to choose from (\"Sell Position A\" and \"Sell Position B\"). If no correct sell position is provided, trades will be rejected.   - orders are executed immediately - ISIN DE0007472060 (Wirecard)   - test instrument for `empty orderModelsBuy` / `onlySellAllowed` - ISIN BTC (Bitcoin/Euro)   - has one exchange with support for quote, market and limit orders   - orders will be executed right away (with the exception of limit orders with the limit 42. Those stay open!)   - can be used to test frontend mapping of cryptos   - when you prepare a trade in the *second* portfolio (which has two cash accounts), `sizeUnitsByCashAccountId` will be set, so that the frontend can let the user select a combination of `cashAccount` and `sizeUnit`.   - positions of BTC/EUR will always have sizeDecimals=8 - ISIN DE0006231004 (Infineon Technologies AG)   - one exchange with `orderModelsSell=[\'market\']` and `orderModelsBuy=[]` - ISIN DE0005552004 (Deutsche Post AG)   - one exchange with `orderModelsSell=[]` and `orderModelsBuy=[\'market\']`   - market buy orders are executed immediately   - positions of DE0005552004 will always have sizeDecimals=undefined - ISIN US8740541094 (Take Two)   - three exchanges are available. all have `market` and `limit` available   - configuration for `takeProfitStopLoss` is different for the three exchanges. This can be used to test the implementation of takeProfit/stopLoss creation.     - exchange_with_exclusive_tp_sl: `takeProfitStopLoss.exclusive` is `true`, so that only one of the two can be set. Also, both fields are limited to market buy orders     - exchange_with_unlimited_tp_sl: `takeProfitStopLoss.exclusive` is `false`, so that both tp and sl may be set, for both sell and buy orders and both support orderModels     - exchange_without_tp_sl: `takeProfitStopLoss` is not set, so that no tp/sl can be set   - orders stay open forever   - the order size can be changed (`allowsChangeSize=true`) - ISIN US5529531015 (MGM Resorts International)   - one exchange with market and limit orders   - orders are executed immediately   - short selling is allowed, so `availableOrderIntents` as well as `availableOrderIntentsToken` is set. \"sell to open\" and \"buy to close\" can be tested here. - ISIN XAU (Gold)   - only quote trading is allowed   - depending on the selected portfolio, it is possible to select a cash account (e.g. EUR or USD) to trade with   - users can chose between specifying the order size in the cash currency or in grams   - quotes have the `totalAmount` field set - ISIN US88160R1014 (Tesla)   - market, limit, stop buy trading is allowed   - `GetCostEstimation` returns order fees   - orders will be executed   - order fees are saved for the order and returned in the order receipt - `CryptoPair` ADA-USD (Cardano - US Dollar)   - `quote`, `market`, `limit` order models are available   - One of the created demobroker portfolios does not have an USD cash account. For this portfolio an error will appear upon opening the order form   - users can chose between specifying the order size in the cash currency (USD) or in ADA   - validity types for limit orders are [`IOC`, `GTDT`]. With `GTDT` the user can specify a date AND time at which his order should be executed   - the size input decimal places are limited per sizeUnit. For USD it\'s 2 and for ADA it is 4 decimal places   - the orders will be executed after 10 seconds - ISIN US23804L1035 (Datadog Inc.)   - only  quote orders are available   - in 80% of `CreateTrade` calls, a 400 error with the code `QUOTE_REJECTED_RETRYABLE` is returned. This can be used to test UIs which automatically retry `GetQuote` in this case. - all other orders will be canceled after 3 seconds  When orders are created using a `decoupled` method, the order id is only returned if the order size is greater than `5`. This can be used to test if the order receipt is skipped correctly in UIs.  Cost estimations for `buy` and `sell` return a different set of fields. This can be used to test proper UI behavior when fields are set or unavailable.  Behavior of `PortfolioQuotes` in the demo broker: - portfolio 1 starts with 100.000€ cash. portfolio 2 has two cash accounts, one starts with 100.000€, one with 100.000$. - when cash account values are summed up, we just assume an exchange rate of 1:1 - each open buy order reserves 10€ cash from the availableCash - profit loss of the portfolio is the sum of the position\'s profit loss - if a EUR cashAccount has the value 0,00€, its `hideInOverviews` property is set to true. This can be used to test the frontend\'s behavior when a cash account is hidden.
+     * Create an account at the demo broker for the logged-in user. The account will have a default set of two empty portfolios by default. If the setting `isSinglePortfolio` is set, only one portfolio is created.  The account as well as the two portfolios have a randomly generated name.  To log into an account, use the account\'s generated name as username (Account name) in `AddSession`. - with the password `42`, the login will succeed immediately - with the password `1337`, a challenge with type text will be returned which must be completed by using `addSessionCompleteChallenge` (with a challengeResponse `42`) - with the password `7`, a challenge with type base64png will be returned which must be completed by using `addSessionCompleteChallenge` (with a challengeResponse `42`) - other passwords will not allow to log in  The demo broker implements the following pre-defined trade behaviors, so that different flows can be tested: - ISIN US0378331005 (Apple):   - market buy order is executed after 10 seconds by the backend at a random quote   - stop buy or stop loss order stays open forever (can be used for testing cancellation)   - cost estimations contain a `costDetailsLink` and a `costAcceptancePrompt`   - securityDetailedInfo is set, so a \"KID\" link should be displayed and linked to the corresponding table   - the preparedTrade\'s `costEstimationMustBeShown` is true, so that the correct behavior (users cannot skip cost estimation in that case) can be tested. - ISIN LU0378438732 (a DAX ETF)   - preparedTrade has `costEstimationIsOnlyDetailedTable` set to true, so that deviating order form behaviors can be tested   - orders are rejected with code `ORDER_REJECTED` immediately - ISIN LU2611732046 (a DAX ETF)   - preparedTrade has `costEstimationIsOnlyDetailedTable` set to true, so that deviating order form behaviors can be tested   - two exchanges are available (\"xetra\" and \"quoteExchange\")   - xetra allows market and limit orders for buying and has defaultValidityByOrderModel set to GFD for market and GTD 2030-01-01 for limit   - orders are rejected with code `ORDER_REJECTED` immediately - ISIN DE000MD96WE8 (a knock out with DAX as underlying)   - prepareTrade is rejected with a message that the user may not trade risky derivatives. - ISIN DE000DTR0CK8 (Daimler Truck Holding)   - prepareTrade is rejected with a message that the user may not trade risky derivatives. - ISIN US4180561072 (Hasbro)   - only quote orders on one exchange are supported   - the quotes are valid for 45 seconds   - quote value is always `42`   - the order gets executed immediately - ISIN DE0005557508 (Deutsche Telekom)   - only quote orders on two different exchanges are supported   - the quotes do *NOT* have an expiration   - quote value is always `42`   - quote comes together with a costEstimation. Subsequent getCostEstimation calls are not allowed.   - `noExchangeDefault` is true, so that exchange must be selected by the user   - order will be canceled after 3 seconds - ISIN US98980L1017 (Zoom)   - only market orders (both buy and sell) are suppored on one exchange   - orders are executed immediately at a random quote   - order creation requires the user to accept a hint (i.e. first try will result in a `MUST_ACCEPT_HINT` error)   - default validity is set to `GTD` with a date of `2030-01-01` - ISIN US29786A1060 (Etsy)   - the prepareTrade request takes 5 seconds   - create challenge takes 5 seconds. for authMethod photoTAN, the challenge will return with an error after that period of time   - only quote and market orders allowed   - at exchange \"Slow exchange\" it takes 7 seconds to get a quote as well as 7 seconds to retrieve order costs   - at exchange \"Exchange with quote and cost errors\" the quote request as well as cost estimation will end with an error after 3 seconds   - the preparedTrade\'s `costEstimationMustBeShown` is true, so that the correct behavior (users cannot skip cost estimation in that case) can be tested. - ISIN XS2149280948 (bond from Bertelsmann)   - quote, limit and market orders (both buy and sell) are supported on one exchange   - limit orders are executed at exactly the limit price   - market orders are executed at a random quote between 90 and 150 percent   - for market orders, there is a legal message to confirm set (`legalMessagesToConfirmByOrderModel`) - ISIN US64110L1061 (Netflix Inc.)   - one exchange with only quote order   - creating the quote order will return an error (quote expired)  - ISIN US67066G1040 (NVIDIA)    - one exchange with only quote order, allowsQuoteModeLimit=true    - quote orders are executed immediately.      - if a quoteLimit is provided, execution happen at quoteLimit value      - otherwise, a random execution quote will be used - ISIN DE000BAY0017 (Bayer AG)   - one exchange with only market order   - `costEstimationIsNotAvailable` is true, so no cost estimations should be linked/shown   - orders will be canceled after 3 seconds - ISIN DE000PAH0038 (Porsche)   - one exchange with only market order   - all orders will be canceled   - `GetCostEstimation` contains (only) a link to a PDF document. This can be used to test whether linking to a PDF works.   - the instrument has both a `riskClassInfo.legalHint` as well as a `strikingHint`. Both should be visible in the order form. - ISIN DE0008404005 (Allianz) and some other hidden ISINs (can be requested from brokerize support)   - one exchange with all available orderModels   - orders are executed immediately   - limit orders are executed at exactly the provided limit price - ISIN DE0008430026 (Munich Re)   - one exchange (L&S) with all available orderModels   - orders are executed immediately - ISIN FR0000120321 (L\'Oréal)   - one exchange with all available orderModels   - the exchange has a `securityQuotesToken` set   - orders stay open   - changesHaveCostEstimations is `true` for orders with this ISIN - ISIN US5949181045 (Microsoft)   - one exchange with all available orderModels   - if size is even, a partial execution with size 1 is executed, the remaining part stays open   - if size is odd, a partial execution with size 1 is executed, the remaining part is canceled - ISIN US30303M1027 (Meta)   - one exchange with all available orderModels   - for each piece of the order size, there will be one execution with size 1 (so e.g. 10 executions for size 10)   - sizes > 30 are not accepted - ISIN US2546871060 (Disney)   - one exchange with all available orderModels   - all orders are canceled after 3s   - `costEstimationMustBeShown` is false and `costEstimationIsOnlyDetailedTable` is true (frontends must only show a link to the cost estimation table) - ISIN XX1234567890 (example of an ISIN that can never be mapped by frontends)   - one exchange with all available orderModels   - the instrument has two sellPositions to choose from (\"Sell Position A\" and \"Sell Position B\"). If no correct sell position is provided, trades will be rejected.   - orders are executed immediately - ISIN DE0007100000 (Mercedes-Benz)   - one exchange with all available orderModels   - the instrument has two sellPositions to choose from (\"Sell Position A\" and \"Sell Position B\"). If no correct sell position is provided, trades will be rejected.   - orders are executed immediately - ISIN DE0007472060 (Wirecard)   - test instrument for `empty orderModelsBuy` / `onlySellAllowed` - ISIN BTC (Bitcoin/Euro)   - has one exchange with support for quote, market and limit orders   - orders will be executed right away (with the exception of limit orders with the limit 42. Those stay open!)   - can be used to test frontend mapping of cryptos   - when you prepare a trade in the *second* portfolio (which has two cash accounts), `sizeUnitsByCashAccountId` will be set, so that the frontend can let the user select a combination of `cashAccount` and `sizeUnit`.   - positions of BTC/EUR will always have sizeDecimals=8 - ISIN DE0006231004 (Infineon Technologies AG)   - one exchange with `orderModelsSell=[\'market\']` and `orderModelsBuy=[]` - ISIN DE0005552004 (Deutsche Post AG)   - one exchange with `orderModelsSell=[]` and `orderModelsBuy=[\'market\']`   - market buy orders are executed immediately   - positions of DE0005552004 will always have sizeDecimals=undefined - ISIN US8740541094 (Take Two)   - three exchanges are available. all have `market` and `limit` available   - configuration for `takeProfitStopLoss` is different for the three exchanges. This can be used to test the implementation of takeProfit/stopLoss creation.     - exchange_with_exclusive_tp_sl: `takeProfitStopLoss.exclusive` is `true`, so that only one of the two can be set. Also, both fields are limited to market buy orders     - exchange_with_unlimited_tp_sl: `takeProfitStopLoss.exclusive` is `false`, so that both tp and sl may be set, for both sell and buy orders and both support orderModels     - exchange_without_tp_sl: `takeProfitStopLoss` is not set, so that no tp/sl can be set   - orders stay open forever   - the order size can be changed (`allowsChangeSize=true`) - ISIN US5529531015 (MGM Resorts International)   - one exchange with market and limit orders   - orders are executed immediately   - short selling is allowed, so `availableOrderIntents` as well as `availableOrderIntentsToken` is set. \"sell to open\" and \"buy to close\" can be tested here. - ISIN XAU (Gold)   - only quote trading is allowed   - depending on the selected portfolio, it is possible to select a cash account (e.g. EUR or USD) to trade with   - users can chose between specifying the order size in the cash currency or in grams   - quotes have the `totalAmount` field set - ISIN US88160R1014 (Tesla)   - market, limit, stop buy trading is allowed   - `GetCostEstimation` returns order fees   - orders will be executed   - order fees are saved for the order and returned in the order receipt - `CryptoPair` ADA-USD (Cardano - US Dollar)   - `quote`, `market`, `limit` order models are available   - One of the created demobroker portfolios does not have an USD cash account. For this portfolio an error will appear upon opening the order form   - users can chose between specifying the order size in the cash currency (USD) or in ADA   - validity types for limit orders are [`IOC`, `GTDT`]. With `GTDT` the user can specify a date AND time at which his order should be executed   - the size input decimal places are limited per sizeUnit. For USD it\'s 2 and for ADA it is 4 decimal places   - the orders will be executed after 10 seconds - ISIN US23804L1035 (Datadog Inc.)   - only  quote orders are available   - in 80% of `CreateTrade` calls, a 400 error with the code `QUOTE_REJECTED_RETRYABLE` is returned. This can be used to test UIs which automatically retry `GetQuote` in this case. - ISIN DE0006969603 (Puma SE)   - one exchange with all orderModels   - orders stay open forever   - `allowsChangeValidityTypes` is empty, so it is not possible to change the order validity   - `changesHaveCostEstimations=false`, so it is not possible to receive cost estimations for order changes) - all other orders will be canceled after 3 seconds  When orders are created using a `decoupled` method, the order id is only returned if the order size is greater than `5`. This can be used to test if the order receipt is skipped correctly in UIs.  Cost estimations for `buy` and `sell` return a different set of fields. This can be used to test proper UI behavior when fields are set or unavailable.  Behavior of `PortfolioQuotes` in the demo broker: - portfolio 1 starts with 100.000€ cash. portfolio 2 has two cash accounts, one starts with 100.000€, one with 100.000$. - when cash account values are summed up, we just assume an exchange rate of 1:1 - each open buy order reserves 10€ cash from the availableCash - profit loss of the portfolio is the sum of the position\'s profit loss - if a EUR cashAccount has the value 0,00€, its `hideInOverviews` property is set to true. This can be used to test the frontend\'s behavior when a cash account is hidden.
      */
     createDemoAccountRaw(requestParameters: CreateDemoAccountRequest, initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<runtime.ApiResponse<CreatedResponseBody>>;
     /**
-     * Create an account at the demo broker for the logged-in user. The account will have a default set of two empty portfolios by default. If the setting `isSinglePortfolio` is set, only one portfolio is created.  The account as well as the two portfolios have a randomly generated name.  To log into an account, use the account\'s generated name as username (Account name) in `AddSession`. - with the password `42`, the login will succeed immediately - with the password `1337`, a challenge with type text will be returned which must be completed by using `addSessionCompleteChallenge` (with a challengeResponse `42`) - with the password `7`, a challenge with type base64png will be returned which must be completed by using `addSessionCompleteChallenge` (with a challengeResponse `42`) - other passwords will not allow to log in  The demo broker implements the following pre-defined trade behaviors, so that different flows can be tested: - ISIN US0378331005 (Apple):   - market buy order is executed after 10 seconds by the backend at a random quote   - stop buy or stop loss order stays open forever (can be used for testing cancellation)   - cost estimations contain a `costDetailsLink` and a `costAcceptancePrompt`   - securityDetailedInfo is set, so a \"KID\" link should be displayed and linked to the corresponding table   - the preparedTrade\'s `costEstimationMustBeShown` is true, so that the correct behavior (users cannot skip cost estimation in that case) can be tested. - ISIN LU0378438732 (a DAX ETF)   - preparedTrade has `costEstimationIsOnlyDetailedTable` set to true, so that deviating order form behaviors can be tested   - orders are rejected with code `ORDER_REJECTED` immediately - ISIN LU2611732046 (a DAX ETF)   - preparedTrade has `costEstimationIsOnlyDetailedTable` set to true, so that deviating order form behaviors can be tested   - two exchanges are available (\"xetra\" and \"quoteExchange\")   - xetra allows market and limit orders for buying and has defaultValidityByOrderModel set to GFD for market and GTD 2030-01-01 for limit   - orders are rejected with code `ORDER_REJECTED` immediately - ISIN DE000MD96WE8 (a knock out with DAX as underlying)   - prepareTrade is rejected with a message that the user may not trade risky derivatives. - ISIN DE000DTR0CK8 (Daimler Truck Holding)   - prepareTrade is rejected with a message that the user may not trade risky derivatives. - ISIN US4180561072 (Hasbro)   - only quote orders on one exchange are supported   - the quotes are valid for 45 seconds   - quote value is always `42`   - the order gets executed immediately - ISIN DE0005557508 (Deutsche Telekom)   - only quote orders on two different exchanges are supported   - the quotes do *NOT* have an expiration   - quote value is always `42`   - quote comes together with a costEstimation. Subsequent getCostEstimation calls are not allowed.   - `noExchangeDefault` is true, so that exchange must be selected by the user   - order will be canceled after 3 seconds - ISIN US98980L1017 (Zoom)   - only market orders (both buy and sell) are suppored on one exchange   - orders are executed immediately at a random quote   - order creation requires the user to accept a hint (i.e. first try will result in a `MUST_ACCEPT_HINT` error)   - default validity is set to `GTD` with a date of `2030-01-01` - ISIN US29786A1060 (Etsy)   - the prepareTrade request takes 5 seconds   - create challenge takes 5 seconds. for authMethod photoTAN, the challenge will return with an error after that period of time   - only quote and market orders allowed   - at exchange \"Slow exchange\" it takes 7 seconds to get a quote as well as 7 seconds to retrieve order costs   - at exchange \"Exchange with quote and cost errors\" the quote request as well as cost estimation will end with an error after 3 seconds   - the preparedTrade\'s `costEstimationMustBeShown` is true, so that the correct behavior (users cannot skip cost estimation in that case) can be tested. - ISIN XS2149280948 (bond from Bertelsmann)   - quote, limit and market orders (both buy and sell) are supported on one exchange   - limit orders are executed at exactly the limit price   - market orders are executed at a random quote between 90 and 150 percent   - for market orders, there is a legal message to confirm set (`legalMessagesToConfirmByOrderModel`) - ISIN US64110L1061 (Netflix Inc.)   - one exchange with only quote order   - creating the quote order will return an error (quote expired)  - ISIN US67066G1040 (NVIDIA)    - one exchange with only quote order, allowsQuoteModeLimit=true    - quote orders are executed immediately.      - if a quoteLimit is provided, execution happen at quoteLimit value      - otherwise, a random execution quote will be used - ISIN DE000BAY0017 (Bayer AG)   - one exchange with only market order   - `costEstimationIsNotAvailable` is true, so no cost estimations should be linked/shown   - orders will be canceled after 3 seconds - ISIN DE000PAH0038 (Porsche)   - one exchange with only market order   - all orders will be canceled   - `GetCostEstimation` contains (only) a link to a PDF document. This can be used to test whether linking to a PDF works.   - the instrument has both a `riskClassInfo.legalHint` as well as a `strikingHint`. Both should be visible in the order form. - ISIN DE0008404005 (Allianz) and some other hidden ISINs (can be requested from brokerize support)   - one exchange with all available orderModels   - orders are executed immediately   - limit orders are executed at exactly the provided limit price - ISIN DE0008430026 (Munich Re)   - one exchange (L&S) with all available orderModels   - orders are executed immediately - ISIN FR0000120321 (L\'Oréal)   - one exchange with all available orderModels   - the exchange has a `securityQuotesToken` set   - orders stay open   - changesHaveCostEstimations is `true` for orders with this ISIN - ISIN US5949181045 (Microsoft)   - one exchange with all available orderModels   - if size is even, a partial execution with size 1 is executed, the remaining part stays open   - if size is odd, a partial execution with size 1 is executed, the remaining part is canceled - ISIN US30303M1027 (Meta)   - one exchange with all available orderModels   - for each piece of the order size, there will be one execution with size 1 (so e.g. 10 executions for size 10)   - sizes > 30 are not accepted - ISIN US2546871060 (Disney)   - one exchange with all available orderModels   - all orders are canceled after 3s   - `costEstimationMustBeShown` is false and `costEstimationIsOnlyDetailedTable` is true (frontends must only show a link to the cost estimation table) - ISIN XX1234567890 (example of an ISIN that can never be mapped by frontends)   - one exchange with all available orderModels   - the instrument has two sellPositions to choose from (\"Sell Position A\" and \"Sell Position B\"). If no correct sell position is provided, trades will be rejected.   - orders are executed immediately - ISIN DE0007100000 (Mercedes-Benz)   - one exchange with all available orderModels   - the instrument has two sellPositions to choose from (\"Sell Position A\" and \"Sell Position B\"). If no correct sell position is provided, trades will be rejected.   - orders are executed immediately - ISIN DE0007472060 (Wirecard)   - test instrument for `empty orderModelsBuy` / `onlySellAllowed` - ISIN BTC (Bitcoin/Euro)   - has one exchange with support for quote, market and limit orders   - orders will be executed right away (with the exception of limit orders with the limit 42. Those stay open!)   - can be used to test frontend mapping of cryptos   - when you prepare a trade in the *second* portfolio (which has two cash accounts), `sizeUnitsByCashAccountId` will be set, so that the frontend can let the user select a combination of `cashAccount` and `sizeUnit`.   - positions of BTC/EUR will always have sizeDecimals=8 - ISIN DE0006231004 (Infineon Technologies AG)   - one exchange with `orderModelsSell=[\'market\']` and `orderModelsBuy=[]` - ISIN DE0005552004 (Deutsche Post AG)   - one exchange with `orderModelsSell=[]` and `orderModelsBuy=[\'market\']`   - market buy orders are executed immediately   - positions of DE0005552004 will always have sizeDecimals=undefined - ISIN US8740541094 (Take Two)   - three exchanges are available. all have `market` and `limit` available   - configuration for `takeProfitStopLoss` is different for the three exchanges. This can be used to test the implementation of takeProfit/stopLoss creation.     - exchange_with_exclusive_tp_sl: `takeProfitStopLoss.exclusive` is `true`, so that only one of the two can be set. Also, both fields are limited to market buy orders     - exchange_with_unlimited_tp_sl: `takeProfitStopLoss.exclusive` is `false`, so that both tp and sl may be set, for both sell and buy orders and both support orderModels     - exchange_without_tp_sl: `takeProfitStopLoss` is not set, so that no tp/sl can be set   - orders stay open forever   - the order size can be changed (`allowsChangeSize=true`) - ISIN US5529531015 (MGM Resorts International)   - one exchange with market and limit orders   - orders are executed immediately   - short selling is allowed, so `availableOrderIntents` as well as `availableOrderIntentsToken` is set. \"sell to open\" and \"buy to close\" can be tested here. - ISIN XAU (Gold)   - only quote trading is allowed   - depending on the selected portfolio, it is possible to select a cash account (e.g. EUR or USD) to trade with   - users can chose between specifying the order size in the cash currency or in grams   - quotes have the `totalAmount` field set - ISIN US88160R1014 (Tesla)   - market, limit, stop buy trading is allowed   - `GetCostEstimation` returns order fees   - orders will be executed   - order fees are saved for the order and returned in the order receipt - `CryptoPair` ADA-USD (Cardano - US Dollar)   - `quote`, `market`, `limit` order models are available   - One of the created demobroker portfolios does not have an USD cash account. For this portfolio an error will appear upon opening the order form   - users can chose between specifying the order size in the cash currency (USD) or in ADA   - validity types for limit orders are [`IOC`, `GTDT`]. With `GTDT` the user can specify a date AND time at which his order should be executed   - the size input decimal places are limited per sizeUnit. For USD it\'s 2 and for ADA it is 4 decimal places   - the orders will be executed after 10 seconds - ISIN US23804L1035 (Datadog Inc.)   - only  quote orders are available   - in 80% of `CreateTrade` calls, a 400 error with the code `QUOTE_REJECTED_RETRYABLE` is returned. This can be used to test UIs which automatically retry `GetQuote` in this case. - all other orders will be canceled after 3 seconds  When orders are created using a `decoupled` method, the order id is only returned if the order size is greater than `5`. This can be used to test if the order receipt is skipped correctly in UIs.  Cost estimations for `buy` and `sell` return a different set of fields. This can be used to test proper UI behavior when fields are set or unavailable.  Behavior of `PortfolioQuotes` in the demo broker: - portfolio 1 starts with 100.000€ cash. portfolio 2 has two cash accounts, one starts with 100.000€, one with 100.000$. - when cash account values are summed up, we just assume an exchange rate of 1:1 - each open buy order reserves 10€ cash from the availableCash - profit loss of the portfolio is the sum of the position\'s profit loss - if a EUR cashAccount has the value 0,00€, its `hideInOverviews` property is set to true. This can be used to test the frontend\'s behavior when a cash account is hidden.
+     * Create an account at the demo broker for the logged-in user. The account will have a default set of two empty portfolios by default. If the setting `isSinglePortfolio` is set, only one portfolio is created.  The account as well as the two portfolios have a randomly generated name.  To log into an account, use the account\'s generated name as username (Account name) in `AddSession`. - with the password `42`, the login will succeed immediately - with the password `1337`, a challenge with type text will be returned which must be completed by using `addSessionCompleteChallenge` (with a challengeResponse `42`) - with the password `7`, a challenge with type base64png will be returned which must be completed by using `addSessionCompleteChallenge` (with a challengeResponse `42`) - other passwords will not allow to log in  The demo broker implements the following pre-defined trade behaviors, so that different flows can be tested: - ISIN US0378331005 (Apple):   - market buy order is executed after 10 seconds by the backend at a random quote   - stop buy or stop loss order stays open forever (can be used for testing cancellation)   - cost estimations contain a `costDetailsLink` and a `costAcceptancePrompt`   - securityDetailedInfo is set, so a \"KID\" link should be displayed and linked to the corresponding table   - the preparedTrade\'s `costEstimationMustBeShown` is true, so that the correct behavior (users cannot skip cost estimation in that case) can be tested. - ISIN LU0378438732 (a DAX ETF)   - preparedTrade has `costEstimationIsOnlyDetailedTable` set to true, so that deviating order form behaviors can be tested   - orders are rejected with code `ORDER_REJECTED` immediately - ISIN LU2611732046 (a DAX ETF)   - preparedTrade has `costEstimationIsOnlyDetailedTable` set to true, so that deviating order form behaviors can be tested   - two exchanges are available (\"xetra\" and \"quoteExchange\")   - xetra allows market and limit orders for buying and has defaultValidityByOrderModel set to GFD for market and GTD 2030-01-01 for limit   - orders are rejected with code `ORDER_REJECTED` immediately - ISIN DE000MD96WE8 (a knock out with DAX as underlying)   - prepareTrade is rejected with a message that the user may not trade risky derivatives. - ISIN DE000DTR0CK8 (Daimler Truck Holding)   - prepareTrade is rejected with a message that the user may not trade risky derivatives. - ISIN US4180561072 (Hasbro)   - only quote orders on one exchange are supported   - the quotes are valid for 45 seconds   - quote value is always `42`   - the order gets executed immediately - ISIN DE0005557508 (Deutsche Telekom)   - only quote orders on two different exchanges are supported   - the quotes do *NOT* have an expiration   - quote value is always `42`   - quote comes together with a costEstimation. Subsequent getCostEstimation calls are not allowed.   - `noExchangeDefault` is true, so that exchange must be selected by the user   - order will be canceled after 3 seconds - ISIN US98980L1017 (Zoom)   - only market orders (both buy and sell) are suppored on one exchange   - orders are executed immediately at a random quote   - order creation requires the user to accept a hint (i.e. first try will result in a `MUST_ACCEPT_HINT` error)   - default validity is set to `GTD` with a date of `2030-01-01` - ISIN US29786A1060 (Etsy)   - the prepareTrade request takes 5 seconds   - create challenge takes 5 seconds. for authMethod photoTAN, the challenge will return with an error after that period of time   - only quote and market orders allowed   - at exchange \"Slow exchange\" it takes 7 seconds to get a quote as well as 7 seconds to retrieve order costs   - at exchange \"Exchange with quote and cost errors\" the quote request as well as cost estimation will end with an error after 3 seconds   - the preparedTrade\'s `costEstimationMustBeShown` is true, so that the correct behavior (users cannot skip cost estimation in that case) can be tested. - ISIN XS2149280948 (bond from Bertelsmann)   - quote, limit and market orders (both buy and sell) are supported on one exchange   - limit orders are executed at exactly the limit price   - market orders are executed at a random quote between 90 and 150 percent   - for market orders, there is a legal message to confirm set (`legalMessagesToConfirmByOrderModel`) - ISIN US64110L1061 (Netflix Inc.)   - one exchange with only quote order   - creating the quote order will return an error (quote expired)  - ISIN US67066G1040 (NVIDIA)    - one exchange with only quote order, allowsQuoteModeLimit=true    - quote orders are executed immediately.      - if a quoteLimit is provided, execution happen at quoteLimit value      - otherwise, a random execution quote will be used - ISIN DE000BAY0017 (Bayer AG)   - one exchange with only market order   - `costEstimationIsNotAvailable` is true, so no cost estimations should be linked/shown   - orders will be canceled after 3 seconds - ISIN DE000PAH0038 (Porsche)   - one exchange with only market order   - all orders will be canceled   - `GetCostEstimation` contains (only) a link to a PDF document. This can be used to test whether linking to a PDF works.   - the instrument has both a `riskClassInfo.legalHint` as well as a `strikingHint`. Both should be visible in the order form. - ISIN DE0008404005 (Allianz) and some other hidden ISINs (can be requested from brokerize support)   - one exchange with all available orderModels   - orders are executed immediately   - limit orders are executed at exactly the provided limit price - ISIN DE0008430026 (Munich Re)   - one exchange (L&S) with all available orderModels   - orders are executed immediately - ISIN FR0000120321 (L\'Oréal)   - one exchange with all available orderModels   - the exchange has a `securityQuotesToken` set   - orders stay open   - changesHaveCostEstimations is `true` for orders with this ISIN - ISIN US5949181045 (Microsoft)   - one exchange with all available orderModels   - if size is even, a partial execution with size 1 is executed, the remaining part stays open   - if size is odd, a partial execution with size 1 is executed, the remaining part is canceled - ISIN US30303M1027 (Meta)   - one exchange with all available orderModels   - for each piece of the order size, there will be one execution with size 1 (so e.g. 10 executions for size 10)   - sizes > 30 are not accepted - ISIN US2546871060 (Disney)   - one exchange with all available orderModels   - all orders are canceled after 3s   - `costEstimationMustBeShown` is false and `costEstimationIsOnlyDetailedTable` is true (frontends must only show a link to the cost estimation table) - ISIN XX1234567890 (example of an ISIN that can never be mapped by frontends)   - one exchange with all available orderModels   - the instrument has two sellPositions to choose from (\"Sell Position A\" and \"Sell Position B\"). If no correct sell position is provided, trades will be rejected.   - orders are executed immediately - ISIN DE0007100000 (Mercedes-Benz)   - one exchange with all available orderModels   - the instrument has two sellPositions to choose from (\"Sell Position A\" and \"Sell Position B\"). If no correct sell position is provided, trades will be rejected.   - orders are executed immediately - ISIN DE0007472060 (Wirecard)   - test instrument for `empty orderModelsBuy` / `onlySellAllowed` - ISIN BTC (Bitcoin/Euro)   - has one exchange with support for quote, market and limit orders   - orders will be executed right away (with the exception of limit orders with the limit 42. Those stay open!)   - can be used to test frontend mapping of cryptos   - when you prepare a trade in the *second* portfolio (which has two cash accounts), `sizeUnitsByCashAccountId` will be set, so that the frontend can let the user select a combination of `cashAccount` and `sizeUnit`.   - positions of BTC/EUR will always have sizeDecimals=8 - ISIN DE0006231004 (Infineon Technologies AG)   - one exchange with `orderModelsSell=[\'market\']` and `orderModelsBuy=[]` - ISIN DE0005552004 (Deutsche Post AG)   - one exchange with `orderModelsSell=[]` and `orderModelsBuy=[\'market\']`   - market buy orders are executed immediately   - positions of DE0005552004 will always have sizeDecimals=undefined - ISIN US8740541094 (Take Two)   - three exchanges are available. all have `market` and `limit` available   - configuration for `takeProfitStopLoss` is different for the three exchanges. This can be used to test the implementation of takeProfit/stopLoss creation.     - exchange_with_exclusive_tp_sl: `takeProfitStopLoss.exclusive` is `true`, so that only one of the two can be set. Also, both fields are limited to market buy orders     - exchange_with_unlimited_tp_sl: `takeProfitStopLoss.exclusive` is `false`, so that both tp and sl may be set, for both sell and buy orders and both support orderModels     - exchange_without_tp_sl: `takeProfitStopLoss` is not set, so that no tp/sl can be set   - orders stay open forever   - the order size can be changed (`allowsChangeSize=true`) - ISIN US5529531015 (MGM Resorts International)   - one exchange with market and limit orders   - orders are executed immediately   - short selling is allowed, so `availableOrderIntents` as well as `availableOrderIntentsToken` is set. \"sell to open\" and \"buy to close\" can be tested here. - ISIN XAU (Gold)   - only quote trading is allowed   - depending on the selected portfolio, it is possible to select a cash account (e.g. EUR or USD) to trade with   - users can chose between specifying the order size in the cash currency or in grams   - quotes have the `totalAmount` field set - ISIN US88160R1014 (Tesla)   - market, limit, stop buy trading is allowed   - `GetCostEstimation` returns order fees   - orders will be executed   - order fees are saved for the order and returned in the order receipt - `CryptoPair` ADA-USD (Cardano - US Dollar)   - `quote`, `market`, `limit` order models are available   - One of the created demobroker portfolios does not have an USD cash account. For this portfolio an error will appear upon opening the order form   - users can chose between specifying the order size in the cash currency (USD) or in ADA   - validity types for limit orders are [`IOC`, `GTDT`]. With `GTDT` the user can specify a date AND time at which his order should be executed   - the size input decimal places are limited per sizeUnit. For USD it\'s 2 and for ADA it is 4 decimal places   - the orders will be executed after 10 seconds - ISIN US23804L1035 (Datadog Inc.)   - only  quote orders are available   - in 80% of `CreateTrade` calls, a 400 error with the code `QUOTE_REJECTED_RETRYABLE` is returned. This can be used to test UIs which automatically retry `GetQuote` in this case. - ISIN DE0006969603 (Puma SE)   - one exchange with all orderModels   - orders stay open forever   - `allowsChangeValidityTypes` is empty, so it is not possible to change the order validity   - `changesHaveCostEstimations=false`, so it is not possible to receive cost estimations for order changes) - all other orders will be canceled after 3 seconds  When orders are created using a `decoupled` method, the order id is only returned if the order size is greater than `5`. This can be used to test if the order receipt is skipped correctly in UIs.  Cost estimations for `buy` and `sell` return a different set of fields. This can be used to test proper UI behavior when fields are set or unavailable.  Behavior of `PortfolioQuotes` in the demo broker: - portfolio 1 starts with 100.000€ cash. portfolio 2 has two cash accounts, one starts with 100.000€, one with 100.000$. - when cash account values are summed up, we just assume an exchange rate of 1:1 - each open buy order reserves 10€ cash from the availableCash - profit loss of the portfolio is the sum of the position\'s profit loss - if a EUR cashAccount has the value 0,00€, its `hideInOverviews` property is set to true. This can be used to test the frontend\'s behavior when a cash account is hidden.
      */
     createDemoAccount(requestParameters?: CreateDemoAccountRequest, initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<CreatedResponseBody>;
     /**
@@ -7158,6 +6994,28 @@ declare function GetQuoteResponseToJSON(value?: GetQuoteResponse | null): any;
 
 declare function GetQuoteResponseToJSONRecursive(value?: GetQuoteResponse | null, ignoreParent?: boolean): any;
 
+/**
+ *
+ * @export
+ * @interface GetRecoveryPhrasesResponse
+ */
+declare interface GetRecoveryPhrasesResponse {
+    /**
+     *
+     * @type {Array<RecoveryPhraseItem>}
+     * @memberof GetRecoveryPhrasesResponse
+     */
+    recoveryPhrases: Array<RecoveryPhraseItem>;
+}
+
+declare function GetRecoveryPhrasesResponseFromJSON(json: any): GetRecoveryPhrasesResponse;
+
+declare function GetRecoveryPhrasesResponseFromJSONTyped(json: any, ignoreDiscriminator: boolean): GetRecoveryPhrasesResponse;
+
+declare function GetRecoveryPhrasesResponseToJSON(value?: GetRecoveryPhrasesResponse | null): any;
+
+declare function GetRecoveryPhrasesResponseToJSONRecursive(value?: GetRecoveryPhrasesResponse | null, ignoreParent?: boolean): any;
+
 declare interface GetSecurityDetailedInfoRequest {
     token: string;
 }
@@ -7200,6 +7058,12 @@ declare interface GetTradeDraftsRequest {
  * @interface GetUserResponse
  */
 declare interface GetUserResponse {
+    /**
+     *
+     * @type {Date}
+     * @memberof GetUserResponse
+     */
+    createdAt: Date;
     /**
      *
      * @type {boolean}
@@ -7668,20 +7532,58 @@ declare function LoginResponseReadyToJSONRecursive(value?: LoginResponseReady |
  *
  * @export
  */
-declare const LoginResponseState: {
-    readonly Ready: "ready";
-    readonly Challenge: "challenge";
-};
-
-declare type LoginResponseState = (typeof LoginResponseState)[keyof typeof LoginResponseState];
+declare const LoginResponseState: {
+    readonly Ready: "ready";
+    readonly Challenge: "challenge";
+};
+
+declare type LoginResponseState = (typeof LoginResponseState)[keyof typeof LoginResponseState];
+
+declare function LoginResponseStateFromJSON(json: any): LoginResponseState;
+
+declare function LoginResponseStateFromJSONTyped(json: any, ignoreDiscriminator: boolean): LoginResponseState;
+
+declare function LoginResponseStateToJSON(value?: LoginResponseState | null): any;
+
+declare function LoginResponseToJSON(value?: LoginResponse | null): any;
+
+/**
+ * brokerize
+ * The brokerize API allows clients to implement multi-brokerage with a unified interface. For more information, visit brokerize.com
+ *
+ *
+ *
+ * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
+ * https://openapi-generator.tech
+ * Do not edit the class manually.
+ */
+/**
+ *
+ * @export
+ * @interface LogoutOkResponseBody
+ */
+declare interface LogoutOkResponseBody {
+    /**
+     * If this is returned, the logout must be completed in the frontend (e.g. when the broker sets cookies for use in their OAuth flow).
+     * @type {string}
+     * @memberof LogoutOkResponseBody
+     */
+    frontendLogoutUrl?: string;
+    /**
+     * A success message to display to the user.
+     * @type {string}
+     * @memberof LogoutOkResponseBody
+     */
+    msg: string;
+}
 
-declare function LoginResponseStateFromJSON(json: any): LoginResponseState;
+declare function LogoutOkResponseBodyFromJSON(json: any): LogoutOkResponseBody;
 
-declare function LoginResponseStateFromJSONTyped(json: any, ignoreDiscriminator: boolean): LoginResponseState;
+declare function LogoutOkResponseBodyFromJSONTyped(json: any, ignoreDiscriminator: boolean): LogoutOkResponseBody;
 
-declare function LoginResponseStateToJSON(value?: LoginResponseState | null): any;
+declare function LogoutOkResponseBodyToJSON(value?: LogoutOkResponseBody | null): any;
 
-declare function LoginResponseToJSON(value?: LoginResponse | null): any;
+declare function LogoutOkResponseBodyToJSONRecursive(value?: LogoutOkResponseBody | null, ignoreParent?: boolean): any;
 
 declare interface LogoutSessionRequest {
     sessionId: string;
@@ -7892,6 +7794,7 @@ declare namespace Models {
         LoginResponseState,
         MaintenanceStatus,
         OkResponseBody,
+        LogoutOkResponseBody,
         Order,
         OrderChanges,
         OrderCostEstimation,
@@ -8036,6 +7939,42 @@ declare function OAuthLoginFormConfigToJSON(value?: OAuthLoginFormConfig | null)
 
 declare function OAuthLoginFormConfigToJSONRecursive(value?: OAuthLoginFormConfig | null, ignoreParent?: boolean): any;
 
+/**
+ * brokerize
+ * The brokerize API allows clients to implement multi-brokerage with a unified interface. For more information, visit brokerize.com
+ *
+ *
+ *
+ * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
+ * https://openapi-generator.tech
+ * Do not edit the class manually.
+ */
+/**
+ *
+ * @export
+ * @interface ObtainTokenByRecoveryPhraseParams
+ */
+declare interface ObtainTokenByRecoveryPhraseParams {
+    /**
+     *
+     * @type {string}
+     * @memberof ObtainTokenByRecoveryPhraseParams
+     */
+    recoveryPhrase: string;
+}
+
+declare function ObtainTokenByRecoveryPhraseParamsFromJSON(json: any): ObtainTokenByRecoveryPhraseParams;
+
+declare function ObtainTokenByRecoveryPhraseParamsFromJSONTyped(json: any, ignoreDiscriminator: boolean): ObtainTokenByRecoveryPhraseParams;
+
+declare function ObtainTokenByRecoveryPhraseParamsToJSON(value?: ObtainTokenByRecoveryPhraseParams | null): any;
+
+declare function ObtainTokenByRecoveryPhraseParamsToJSONRecursive(value?: ObtainTokenByRecoveryPhraseParams | null, ignoreParent?: boolean): any;
+
+declare interface ObtainTokenByRecoveryPhraseRequest {
+    obtainTokenByRecoveryPhraseParams: ObtainTokenByRecoveryPhraseParams;
+}
+
 declare interface ObtainTokenRequest {
     grantType: string;
     refreshToken: string;
@@ -8117,28 +8056,26 @@ declare namespace openApiClient {
         SetClientConfigOperationRequest,
         AdminApi,
         GetOrderReportFormatEnum,
-        AddSessionRequest,
-        AddSessionCompleteChallengeRequest,
-        ConfirmOAuthRequest,
-        PrepareOAuthRedirectRequest,
-        BrokerLoginApi,
+        CancelDecoupledOperationRequest,
+        GetDecoupledOperationStatusRequest,
+        DecoupledOperationsApi,
+        CreateDemoAccountRequest,
+        DeleteDemoAccountRequest,
+        TriggerDemoSessionSyncErrorRequest,
+        DemobrokerApi,
+        RenderGenericTableRequest,
+        ExportApi,
+        GetPagesConfigurationRequest,
+        MetaApi,
         CancelOrderRequest,
-        CreateCancelOrderChallengeRequest,
-        CancelOrderApi,
         ChangeOrderRequest,
+        CreateCancelOrderChallengeRequest,
         CreateChangeOrderChallengeRequest,
         GetChangeOrderCostEstimationRequest,
-        ChangeOrderApi,
-        CancelDecoupledOperationRequest,
-        CancelDecoupledOperationLegacyRequest,
-        CreateSessionTanChallengeRequest,
+        GetOrderRequest,
+        OrderApi,
         DeletePortfolioRequest,
-        EnableSessionTanRequest,
-        EndSessionTanRequest,
         GetAuthInfoRequest,
-        GetDecoupledOperationStatusRequest,
-        GetDecoupledOperationStatusLegacyRequest,
-        GetOrderRequest,
         GetPortfolioCalendarRequest,
         GetPortfolioOrdersRequest,
         GetPortfolioPositionsRequest,
@@ -8146,22 +8083,23 @@ declare namespace openApiClient {
         GetPortfolioTradeStatisticsRequest,
         GetPortfolioTradeWarningsRequest,
         GetPortfolioTradesRequest,
-        LogoutSessionRequest,
-        ObtainTokenRequest,
         RenamePortfolioOperationRequest,
-        TriggerSessionSyncRequest,
-        DefaultApi,
-        CreateDemoAccountRequest,
-        DeleteDemoAccountRequest,
-        TriggerDemoSessionSyncErrorRequest,
-        DemobrokerApi,
-        RenderGenericTableRequest,
-        ExportApi,
-        GetPagesConfigurationRequest,
-        MetaApi,
+        PortfolioApi,
         GetSecurityQuotesRequest,
         GetSecurityQuotesMetaRequest,
         SecuritiesApi,
+        AddSessionRequest,
+        AddSessionCompleteChallengeRequest,
+        CancelDecoupledOperationLegacyRequest,
+        ConfirmOAuthRequest,
+        CreateSessionTanChallengeRequest,
+        EnableSessionTanRequest,
+        EndSessionTanRequest,
+        GetDecoupledOperationStatusLegacyRequest,
+        LogoutSessionRequest,
+        PrepareOAuthRedirectRequest,
+        TriggerSessionSyncRequest,
+        SessionApi,
         CreateTradeRequest,
         CreateTradeChallengeRequest,
         GetAvailableOrderIntentsRequest,
@@ -8176,9 +8114,15 @@ declare namespace openApiClient {
         GetTradeDraftsRequest,
         UpdateTradeDraftRequest,
         TradeDraftApi,
+        CheckRecoveryPhraseRequest,
         CreateAccessTokenRequest,
+        CreateRecoveryPhraseRequest,
+        DeleteRecoveryPhraseRequest,
+        ObtainTokenRequest,
+        ObtainTokenByRecoveryPhraseRequest,
         RevokeAccessTokenRequest,
         UserApi,
+        WebsocketApi,
         AccessTokenItemFromJSON,
         AccessTokenItemFromJSONTyped,
         AccessTokenItemToJSONRecursive,
@@ -8415,6 +8359,11 @@ declare namespace openApiClient {
         ChangeOrderResponseToJSONRecursive,
         ChangeOrderResponseToJSON,
         ChangeOrderResponse,
+        CheckRecoveryPhrase200ResponseFromJSON,
+        CheckRecoveryPhrase200ResponseFromJSONTyped,
+        CheckRecoveryPhrase200ResponseToJSONRecursive,
+        CheckRecoveryPhrase200ResponseToJSON,
+        CheckRecoveryPhrase200Response,
         ClientConfigFromJSON,
         ClientConfigFromJSONTyped,
         ClientConfigToJSONRecursive,
@@ -8514,6 +8463,16 @@ declare namespace openApiClient {
         CreateOrderParamsToJSONRecursive,
         CreateOrderParamsToJSON,
         CreateOrderParams,
+        CreateRecoveryPhraseParamsFromJSON,
+        CreateRecoveryPhraseParamsFromJSONTyped,
+        CreateRecoveryPhraseParamsToJSONRecursive,
+        CreateRecoveryPhraseParamsToJSON,
+        CreateRecoveryPhraseParams,
+        CreateRecoveryPhraseResultFromJSON,
+        CreateRecoveryPhraseResultFromJSONTyped,
+        CreateRecoveryPhraseResultToJSONRecursive,
+        CreateRecoveryPhraseResultToJSON,
+        CreateRecoveryPhraseResult,
         CreateTanChallengeParamsFromJSON,
         CreateTanChallengeParamsFromJSONTyped,
         CreateTanChallengeParamsToJSONRecursive,
@@ -8917,6 +8876,11 @@ declare namespace openApiClient {
         GetQuoteResponseToJSONRecursive,
         GetQuoteResponseToJSON,
         GetQuoteResponse,
+        GetRecoveryPhrasesResponseFromJSON,
+        GetRecoveryPhrasesResponseFromJSONTyped,
+        GetRecoveryPhrasesResponseToJSONRecursive,
+        GetRecoveryPhrasesResponseToJSON,
+        GetRecoveryPhrasesResponse,
         GetUserResponseFromJSON,
         GetUserResponseFromJSONTyped,
         GetUserResponseToJSONRecursive,
@@ -8983,6 +8947,11 @@ declare namespace openApiClient {
         LoginResponseStateFromJSONTyped,
         LoginResponseStateToJSON,
         LoginResponseState,
+        LogoutOkResponseBodyFromJSON,
+        LogoutOkResponseBodyFromJSONTyped,
+        LogoutOkResponseBodyToJSONRecursive,
+        LogoutOkResponseBodyToJSON,
+        LogoutOkResponseBody,
         MaintenanceStatusFromJSON,
         MaintenanceStatusFromJSONTyped,
         MaintenanceStatusToJSONRecursive,
@@ -8995,6 +8964,11 @@ declare namespace openApiClient {
         OAuthLoginFormConfig,
         OAuthLoginFormConfigRedirectStyleEnum,
         OAuthLoginFormConfigRedirectStyleBitpandaEnum,
+        ObtainTokenByRecoveryPhraseParamsFromJSON,
+        ObtainTokenByRecoveryPhraseParamsFromJSONTyped,
+        ObtainTokenByRecoveryPhraseParamsToJSONRecursive,
+        ObtainTokenByRecoveryPhraseParamsToJSON,
+        ObtainTokenByRecoveryPhraseParams,
         OkResponseBodyFromJSON,
         OkResponseBodyFromJSONTyped,
         OkResponseBodyToJSONRecursive,
@@ -9203,6 +9177,11 @@ declare namespace openApiClient {
         QuoteExpirationToJSONRecursive,
         QuoteExpirationToJSON,
         QuoteExpiration,
+        RecoveryPhraseItemFromJSON,
+        RecoveryPhraseItemFromJSONTyped,
+        RecoveryPhraseItemToJSONRecursive,
+        RecoveryPhraseItemToJSON,
+        RecoveryPhraseItem,
         RenamePortfolioRequestFromJSON,
         RenamePortfolioRequestFromJSONTyped,
         RenamePortfolioRequestToJSONRecursive,
@@ -9815,6 +9794,58 @@ declare interface Order {
     validity?: OrderValidity;
 }
 
+/**
+ *
+ */
+declare class OrderApi extends runtime.BaseAPI {
+    /**
+     * Cancel the given order (or in the case of decoupled authMethods: send the order cancellation to the user for confirmation. In this case, a decoupledOperationId is returned).
+     */
+    cancelOrderRaw(requestParameters: CancelOrderRequest, initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<runtime.ApiResponse<CancelOrderResponse>>;
+    /**
+     * Cancel the given order (or in the case of decoupled authMethods: send the order cancellation to the user for confirmation. In this case, a decoupledOperationId is returned).
+     */
+    cancelOrder(requestParameters: CancelOrderRequest, initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<CancelOrderResponse>;
+    /**
+     * Perform an order change.
+     */
+    changeOrderRaw(requestParameters: ChangeOrderRequest, initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<runtime.ApiResponse<ChangeOrderResponse>>;
+    /**
+     * Perform an order change.
+     */
+    changeOrder(requestParameters: ChangeOrderRequest, initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<ChangeOrderResponse>;
+    /**
+     * If the user chose an auth method from `GetAuthInfo` with the flow `CHALLENGE_RESPONSE`, before cancelling an order, a challenge must be requested first. If any other flow is used, a challenge *must not* be requested and `CancelOrder` is used right away.
+     */
+    createCancelOrderChallengeRaw(requestParameters: CreateCancelOrderChallengeRequest, initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<runtime.ApiResponse<Challenge>>;
+    /**
+     * If the user chose an auth method from `GetAuthInfo` with the flow `CHALLENGE_RESPONSE`, before cancelling an order, a challenge must be requested first. If any other flow is used, a challenge *must not* be requested and `CancelOrder` is used right away.
+     */
+    createCancelOrderChallenge(requestParameters: CreateCancelOrderChallengeRequest, initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<Challenge>;
+    /**
+     * If the user chose an auth method from `GetAuthInfo` with the flow `CHALLENGE_RESPONSE`, before changing an order, a challenge must be requested first. If any other flow is used, a challenge *must not* be requested and `ChangeOrder` is used right away.
+     */
+    createChangeOrderChallengeRaw(requestParameters: CreateChangeOrderChallengeRequest, initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<runtime.ApiResponse<Challenge>>;
+    /**
+     * If the user chose an auth method from `GetAuthInfo` with the flow `CHALLENGE_RESPONSE`, before changing an order, a challenge must be requested first. If any other flow is used, a challenge *must not* be requested and `ChangeOrder` is used right away.
+     */
+    createChangeOrderChallenge(requestParameters: CreateChangeOrderChallengeRequest, initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<Challenge>;
+    /**
+     * Get an order cost estimation for an order change.
+     */
+    getChangeOrderCostEstimationRaw(requestParameters: GetChangeOrderCostEstimationRequest, initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<runtime.ApiResponse<OrderCostEstimation>>;
+    /**
+     * Get an order cost estimation for an order change.
+     */
+    getChangeOrderCostEstimation(requestParameters: GetChangeOrderCostEstimationRequest, initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<OrderCostEstimation>;
+    /**
+     */
+    getOrderRaw(requestParameters: GetOrderRequest, initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<runtime.ApiResponse<GetOrderResponse>>;
+    /**
+     */
+    getOrder(requestParameters: GetOrderRequest, initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<GetOrderResponse>;
+}
+
 /**
  *
  * @export
@@ -10653,60 +10684,142 @@ declare interface Portfolio {
      * @type {Array<string>}
      * @memberof Portfolio
      */
-    cashAccountIds: Array<string>;
+    cashAccountIds: Array<string>;
+    /**
+     * - ISO code (e.g. EUR for Euro), if it is a monetary amount
+     * - or 'USDT' if its Tether (https://en.wikipedia.org/wiki/Tether_(cryptocurrency)
+     * - or 'XXX' if it is pieces
+     * - or 'PRC' if it is a percentage
+     * - or 'PRM' if it is permil
+     * - or 'XXP' if it is points (as for indices)
+     * - or 'GRAMS' if it is grams (as for precious metals)
+     * @type {string}
+     * @memberof Portfolio
+     */
+    currency: string;
+    /**
+     *
+     * @type {string}
+     * @memberof Portfolio
+     */
+    id: string;
+    /**
+     * A portfolio idHash is a unique identifier used to represent a portfolio within a user account. The idHash is automatically generated based on the original broker id of the portfolio,
+     * meaning that if a portfolio is synchronized into a new user account, it will usually retain the same idHash as in the old account (although it will be assigned a new globally unique id).
+     * When applications use temporary or guest user accounts, it makes sense to use the idHash instead of the id to implement features like "last used portfolio" etc. This is because the idHash remains
+     * the same even if the portfolio is synchronized into a new user account, whereas a new id will be assigned.
+     *
+     * It's important to note that the `idHash` is unique within a user account, meaning that no two portfolios within the same account can have the same idHash.
+     * @type {string}
+     * @memberof Portfolio
+     */
+    idHash: string;
+    /**
+     *
+     * @type {string}
+     * @memberof Portfolio
+     */
+    portfolioName: string;
+    /**
+     *
+     * @type {string}
+     * @memberof Portfolio
+     */
+    portfolioNameOriginal: string;
+    /**
+     *
+     * @type {Array<string>}
+     * @memberof Portfolio
+     */
+    sessionIds: Array<string>;
+    /**
+     *
+     * @type {PortfolioSyncInfo}
+     * @memberof Portfolio
+     */
+    syncInfo: PortfolioSyncInfo;
+}
+
+/**
+ *
+ */
+declare class PortfolioApi extends runtime.BaseAPI {
+    /**
+     */
+    deletePortfolioRaw(requestParameters: DeletePortfolioRequest, initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<runtime.ApiResponse<OkResponseBody>>;
+    /**
+     */
+    deletePortfolio(requestParameters: DeletePortfolioRequest, initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<OkResponseBody>;
+    /**
+     * Get the AuthInfo for the given portfolio.  If the portfolio does not have an online session, this will return a 400 status code.  If it does, the response describes whether session TAN is available or active and which auth methods are available for the given portfolio (this information depends on the broker and the user\'s account settings).  The response determines which of the following operations can be used and which are required to successfully perform an operation in a portfolio:  -   Session TAN handling (for performing other actions in portfolios without further per-case authorization)     -   [CreateSessionTanChallenge](#operation/CreateSessionTanChallenge) to request a challenge for s TAN activation.     -   [EnableSessionTan](#operation/EnableSessionTan) to enable the session TAN.     -   [EndSessionTan](#operation/EndSessionTan) to end the session TAN. -   Create a trade     -   [PrepareTrade](#operation/PrepareTrade) to figure out how a given security can be traded in a portfolio.     -   [CreateTradeChallenge](#operation/CreateTradeChallenge) to (for example) request a TAN for a trade.     -   [CreateTrade](#operation/CreateTrade) to perform the trade. -   Edit an order     -   [CreateChangeOrderChallenge](#operation/CreateChangeOrderChallenge) to request a challenge for an order change.     -   [ChangeOrder](#operation/ChangeOrder) to change an order. -   Cancel an order     -   [CreateCancelOrderChallenge](#operation/CreateCancelOrderChallenge) to request a Challenge for an order cancellation.     -   [CancelOrder](#operation/CancelOrder) to cancel an order.  The list of available AuthMethods should only be presented to the user if session TAN is not active (yet). The list and names are defined by our partner brokers. All auth methods are generally categorized using the `flow` attribute:  | `flow`               | requires challenge? | Description                                                                                                                                                                                                          | | -------------------- | ------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `TAN`                | no                  | the simplest flow: no challenge is required to perform the operation. the TAN is simply sent as parameter `tan`                                                                              | | `CHALLENGE_RESPONSE` | yes                 | a challenge must be created using the `createXYZChallenge` operations and the challenge must be presented to the user. The user can then execute the action using the `challengeId` and `challengeResponse` parameters. If the auth method has `challengeResponseIsOnlyConfirmation=true`, that challengeResponse is always an empty string and users do not enter a TAN. Otherwise, a text field labelled with `tanFieldLabel` must be displayed where the user enteirs their challengeResponse. | | `DECOUPLED`          | no                  | the operation is executed without any TAN, but returns a `decoupledOperationId` which can be used to read the action\'s status. Users will authorize the action in another frontend (usually in their broker\'s app). Note that currently `DECOUPLED` auth methods only work for enabling session TAN.   |  - If `sessionTanActive` is `true`: Session TAN has been enabled for the session that currently backs the portfolio. In this case, all operations like `CreateTrade` can be executed right away without an `authMethod`. The UI should *not* show a dropdown with the auth methods in this case. - If `sessionTanActive` is `false` but `sessionTanSupported` is `true`: the user can enable session TAN using `CreateSessionTanChallenge` / `EnableSessionTan`. - If `allOperationsRequireSessionTan` is `true`, the auth methods can *ONLY* be used for enabling session TAN. - Otherwise, the `authMethods` can be used to perform individual operations.  | sessionTanActive | sessionTanSupported | allOperationsRequireSessionTan | Description                                                                                                                                                                                                                                                 | | ---------------- | ------------------- | ------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `true`           | `true`              | -                              | Session TAN has been enabled for the session that currently backs the portfolio. In this case, all operations like `CreateTrade`, `ChangeOrder`, `CancelOrder` can be executed right away without an `authMethod`. The UI should _not_ show a dropdown with the auth methods in this case. | | `false`          | `true`              | `true`                         | the user can enable session TAN using the provided auth methods via `CreateSessionTanChallenge` / `EnableSessionTan`. All other operations can only take place after session TAN has been enabled.                                                          | | `false`          | `true`              | `false`                        | the user can enable any operation (enable session tan, create trade, cancel order, change order) using the provided auth methods                                                                                                                            |  Note that it is possible that brokers only reveal all details about the available auth methods *TOGETHER* with the first `GetChallenge` request. This special behavior can be simulated with our demo broker when the flag `lazyAuthMethods=true` is specified upon creation of a demo account. In those accounts, the `GetAuthInfo` endpoint will initially return a single \"placeholder\" method with `{flow: \"CHALLENGE_RESPONSE\", isDefaultMethod: true, ...}`.  In the situation where there is *exactly one* auth method like this, frontends may immediately request the challenge for the desired operation without waiting for the user to click the get challenge button (for Session TAN, this means that as soon as the user opens the dialog for enabling session TAN, `CreateSessionTanChallenge` can be called). In the case described here, `AuthInfo` will be populated with the actual list of auth methods when the create challenge request returns (also, the corresponding WebSocket event is published to notify about this change). `GetAuthInfo` must be called again in this case and repopulate the corresponding frontend (e.g. the name of the auth method will become available etc.). So what is done in this case is: request a challenge for the *unknown* default method in order to get both a challenge and an update of the auth methods.  Note that usually challenges have effects like an SMS or some broker app notification for the end user, so it is important to keep the requested challenge info, *even when auth info is refreshed*. For example, if there is a select box with the auth method list, that box must keep its selected `id` while updating the now-available `label`. This way, the user can use the first requested challenge, as the frontend will still be in the right state.
+     */
+    getAuthInfoRaw(requestParameters: GetAuthInfoRequest, initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<runtime.ApiResponse<GetAuthInfoResponse>>;
+    /**
+     * Get the AuthInfo for the given portfolio.  If the portfolio does not have an online session, this will return a 400 status code.  If it does, the response describes whether session TAN is available or active and which auth methods are available for the given portfolio (this information depends on the broker and the user\'s account settings).  The response determines which of the following operations can be used and which are required to successfully perform an operation in a portfolio:  -   Session TAN handling (for performing other actions in portfolios without further per-case authorization)     -   [CreateSessionTanChallenge](#operation/CreateSessionTanChallenge) to request a challenge for s TAN activation.     -   [EnableSessionTan](#operation/EnableSessionTan) to enable the session TAN.     -   [EndSessionTan](#operation/EndSessionTan) to end the session TAN. -   Create a trade     -   [PrepareTrade](#operation/PrepareTrade) to figure out how a given security can be traded in a portfolio.     -   [CreateTradeChallenge](#operation/CreateTradeChallenge) to (for example) request a TAN for a trade.     -   [CreateTrade](#operation/CreateTrade) to perform the trade. -   Edit an order     -   [CreateChangeOrderChallenge](#operation/CreateChangeOrderChallenge) to request a challenge for an order change.     -   [ChangeOrder](#operation/ChangeOrder) to change an order. -   Cancel an order     -   [CreateCancelOrderChallenge](#operation/CreateCancelOrderChallenge) to request a Challenge for an order cancellation.     -   [CancelOrder](#operation/CancelOrder) to cancel an order.  The list of available AuthMethods should only be presented to the user if session TAN is not active (yet). The list and names are defined by our partner brokers. All auth methods are generally categorized using the `flow` attribute:  | `flow`               | requires challenge? | Description                                                                                                                                                                                                          | | -------------------- | ------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `TAN`                | no                  | the simplest flow: no challenge is required to perform the operation. the TAN is simply sent as parameter `tan`                                                                              | | `CHALLENGE_RESPONSE` | yes                 | a challenge must be created using the `createXYZChallenge` operations and the challenge must be presented to the user. The user can then execute the action using the `challengeId` and `challengeResponse` parameters. If the auth method has `challengeResponseIsOnlyConfirmation=true`, that challengeResponse is always an empty string and users do not enter a TAN. Otherwise, a text field labelled with `tanFieldLabel` must be displayed where the user enteirs their challengeResponse. | | `DECOUPLED`          | no                  | the operation is executed without any TAN, but returns a `decoupledOperationId` which can be used to read the action\'s status. Users will authorize the action in another frontend (usually in their broker\'s app). Note that currently `DECOUPLED` auth methods only work for enabling session TAN.   |  - If `sessionTanActive` is `true`: Session TAN has been enabled for the session that currently backs the portfolio. In this case, all operations like `CreateTrade` can be executed right away without an `authMethod`. The UI should *not* show a dropdown with the auth methods in this case. - If `sessionTanActive` is `false` but `sessionTanSupported` is `true`: the user can enable session TAN using `CreateSessionTanChallenge` / `EnableSessionTan`. - If `allOperationsRequireSessionTan` is `true`, the auth methods can *ONLY* be used for enabling session TAN. - Otherwise, the `authMethods` can be used to perform individual operations.  | sessionTanActive | sessionTanSupported | allOperationsRequireSessionTan | Description                                                                                                                                                                                                                                                 | | ---------------- | ------------------- | ------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `true`           | `true`              | -                              | Session TAN has been enabled for the session that currently backs the portfolio. In this case, all operations like `CreateTrade`, `ChangeOrder`, `CancelOrder` can be executed right away without an `authMethod`. The UI should _not_ show a dropdown with the auth methods in this case. | | `false`          | `true`              | `true`                         | the user can enable session TAN using the provided auth methods via `CreateSessionTanChallenge` / `EnableSessionTan`. All other operations can only take place after session TAN has been enabled.                                                          | | `false`          | `true`              | `false`                        | the user can enable any operation (enable session tan, create trade, cancel order, change order) using the provided auth methods                                                                                                                            |  Note that it is possible that brokers only reveal all details about the available auth methods *TOGETHER* with the first `GetChallenge` request. This special behavior can be simulated with our demo broker when the flag `lazyAuthMethods=true` is specified upon creation of a demo account. In those accounts, the `GetAuthInfo` endpoint will initially return a single \"placeholder\" method with `{flow: \"CHALLENGE_RESPONSE\", isDefaultMethod: true, ...}`.  In the situation where there is *exactly one* auth method like this, frontends may immediately request the challenge for the desired operation without waiting for the user to click the get challenge button (for Session TAN, this means that as soon as the user opens the dialog for enabling session TAN, `CreateSessionTanChallenge` can be called). In the case described here, `AuthInfo` will be populated with the actual list of auth methods when the create challenge request returns (also, the corresponding WebSocket event is published to notify about this change). `GetAuthInfo` must be called again in this case and repopulate the corresponding frontend (e.g. the name of the auth method will become available etc.). So what is done in this case is: request a challenge for the *unknown* default method in order to get both a challenge and an update of the auth methods.  Note that usually challenges have effects like an SMS or some broker app notification for the end user, so it is important to keep the requested challenge info, *even when auth info is refreshed*. For example, if there is a select box with the auth method list, that box must keep its selected `id` while updating the now-available `label`. This way, the user can use the first requested challenge, as the frontend will still be in the right state.
+     */
+    getAuthInfo(requestParameters: GetAuthInfoRequest, initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<GetAuthInfoResponse>;
+    /**
+     * Retrieve \"by-day\" aggregated values for the selected date ranges.
+     */
+    getPortfolioCalendarRaw(requestParameters: GetPortfolioCalendarRequest, initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<runtime.ApiResponse<GetPortfolioCalendarResponse>>;
+    /**
+     * Retrieve \"by-day\" aggregated values for the selected date ranges.
+     */
+    getPortfolioCalendar(requestParameters: GetPortfolioCalendarRequest, initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<GetPortfolioCalendarResponse>;
+    /**
+     */
+    getPortfolioOrdersRaw(requestParameters: GetPortfolioOrdersRequest, initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<runtime.ApiResponse<GetPortfolioOrdersResponse>>;
+    /**
+     */
+    getPortfolioOrders(requestParameters: GetPortfolioOrdersRequest, initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<GetPortfolioOrdersResponse>;
+    /**
+     */
+    getPortfolioPositionsRaw(requestParameters: GetPortfolioPositionsRequest, initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<runtime.ApiResponse<GetPortfolioPositionsResponse>>;
+    /**
+     */
+    getPortfolioPositions(requestParameters: GetPortfolioPositionsRequest, initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<GetPortfolioPositionsResponse>;
+    /**
+     */
+    getPortfolioQuotesRaw(requestParameters: GetPortfolioQuotesRequest, initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<runtime.ApiResponse<GetPortfolioQuotesResponse>>;
+    /**
+     */
+    getPortfolioQuotes(requestParameters: GetPortfolioQuotesRequest, initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<GetPortfolioQuotesResponse>;
+    /**
+     * Load statistics based on the trade list for selected date ranges. The statistics (such as `longestWinningStreak` or `tradeCount`) are computed for each of the requested date ranges.
+     */
+    getPortfolioTradeStatisticsRaw(requestParameters: GetPortfolioTradeStatisticsRequest, initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<runtime.ApiResponse<GetPortfolioTradeStatisticsResponse>>;
+    /**
+     * Load statistics based on the trade list for selected date ranges. The statistics (such as `longestWinningStreak` or `tradeCount`) are computed for each of the requested date ranges.
+     */
+    getPortfolioTradeStatistics(requestParameters: GetPortfolioTradeStatisticsRequest, initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<GetPortfolioTradeStatisticsResponse>;
+    /**
+     */
+    getPortfolioTradeWarningsRaw(requestParameters: GetPortfolioTradeWarningsRequest, initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<runtime.ApiResponse<Array<TradeWarning>>>;
     /**
-     * - ISO code (e.g. EUR for Euro), if it is a monetary amount
-     * - or 'USDT' if its Tether (https://en.wikipedia.org/wiki/Tether_(cryptocurrency)
-     * - or 'XXX' if it is pieces
-     * - or 'PRC' if it is a percentage
-     * - or 'PRM' if it is permil
-     * - or 'XXP' if it is points (as for indices)
-     * - or 'GRAMS' if it is grams (as for precious metals)
-     * @type {string}
-     * @memberof Portfolio
      */
-    currency: string;
+    getPortfolioTradeWarnings(requestParameters: GetPortfolioTradeWarningsRequest, initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<Array<TradeWarning>>;
     /**
-     *
-     * @type {string}
-     * @memberof Portfolio
+     * Load a list of completed trades in a portfolio. A completed trade corresponds to *one* closing of a position. Technically each closing of a position corresponds to one execution of an order with `intent=close` (usually those are sell orders, but in the case of short selling, opening a position is a sell order with intent=open).  The analysis follows the FIFO (First In, First Out) principle to accurately summarize trades. Each time a position is closed (note that partial executions are possible. In this case, each individual execution is regarded as a transaction), the system identifies the earliest corresponding \"open position execution\" that contributed to that closing. The result includes a single entry for each closing transaction, detailing key metrics such as profit/loss and holding period, based on the matched opening transactions.  This could be a real world example: - 2020-01-01: buy 5 stock1 for 100 USD each - 2021-06-01: buy 3 stock1 for 200 USD each - 2021-06-06: sell 6 stock1 for 300 USD each  In this case, the result would be one completed trade (corresponding to the last sell) with a profit of `(300*6)-(100*5+1*200)=1800-700=1100 USD`. There is an open position remaining (2 units of stock1, which correspond to the second buy transaction).  When we add this sell: - 2021-06-07: sell 2 stock1 for 400 USD each  It would add a second complete trade with a profit of `(400*2)-(200*2)=800-400=400 USD`.  For some brokers, the order history may be incomplete (e.g. only reveals the latest 90 days), so that we do not know if there could be older transactions. Thus, our implementation might detect (given the current set of open positions together with the list of order executions) that we cannot figure out the corresponding opening transactions for a closing transaction. Affected trades will be ignored for this analysis and might appear as warning items in the `/warnings` endpoint. Frontends should show those warnings so that users can understand why the analysis is incomplete.
      */
-    id: string;
+    getPortfolioTradesRaw(requestParameters: GetPortfolioTradesRequest, initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<runtime.ApiResponse<GetPortfolioTradesResponse>>;
     /**
-     * A portfolio idHash is a unique identifier used to represent a portfolio within a user account. The idHash is automatically generated based on the original broker id of the portfolio,
-     * meaning that if a portfolio is synchronized into a new user account, it will usually retain the same idHash as in the old account (although it will be assigned a new globally unique id).
-     * When applications use temporary or guest user accounts, it makes sense to use the idHash instead of the id to implement features like "last used portfolio" etc. This is because the idHash remains
-     * the same even if the portfolio is synchronized into a new user account, whereas a new id will be assigned.
-     *
-     * It's important to note that the `idHash` is unique within a user account, meaning that no two portfolios within the same account can have the same idHash.
-     * @type {string}
-     * @memberof Portfolio
+     * Load a list of completed trades in a portfolio. A completed trade corresponds to *one* closing of a position. Technically each closing of a position corresponds to one execution of an order with `intent=close` (usually those are sell orders, but in the case of short selling, opening a position is a sell order with intent=open).  The analysis follows the FIFO (First In, First Out) principle to accurately summarize trades. Each time a position is closed (note that partial executions are possible. In this case, each individual execution is regarded as a transaction), the system identifies the earliest corresponding \"open position execution\" that contributed to that closing. The result includes a single entry for each closing transaction, detailing key metrics such as profit/loss and holding period, based on the matched opening transactions.  This could be a real world example: - 2020-01-01: buy 5 stock1 for 100 USD each - 2021-06-01: buy 3 stock1 for 200 USD each - 2021-06-06: sell 6 stock1 for 300 USD each  In this case, the result would be one completed trade (corresponding to the last sell) with a profit of `(300*6)-(100*5+1*200)=1800-700=1100 USD`. There is an open position remaining (2 units of stock1, which correspond to the second buy transaction).  When we add this sell: - 2021-06-07: sell 2 stock1 for 400 USD each  It would add a second complete trade with a profit of `(400*2)-(200*2)=800-400=400 USD`.  For some brokers, the order history may be incomplete (e.g. only reveals the latest 90 days), so that we do not know if there could be older transactions. Thus, our implementation might detect (given the current set of open positions together with the list of order executions) that we cannot figure out the corresponding opening transactions for a closing transaction. Affected trades will be ignored for this analysis and might appear as warning items in the `/warnings` endpoint. Frontends should show those warnings so that users can understand why the analysis is incomplete.
      */
-    idHash: string;
+    getPortfolioTrades(requestParameters: GetPortfolioTradesRequest, initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<GetPortfolioTradesResponse>;
     /**
-     *
-     * @type {string}
-     * @memberof Portfolio
      */
-    portfolioName: string;
+    getPortfoliosRaw(initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<runtime.ApiResponse<PortfoliosResponse>>;
     /**
-     *
-     * @type {string}
-     * @memberof Portfolio
      */
-    portfolioNameOriginal: string;
+    getPortfolios(initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<PortfoliosResponse>;
     /**
-     *
-     * @type {Array<string>}
-     * @memberof Portfolio
+     * This endpoint can be used to rename the display name of a specified portfolio. To restore the original portfolio name, send a rename request with an empty string as the new name. **Note**: This does not change the original portfolio name at your broker.
      */
-    sessionIds: Array<string>;
+    renamePortfolioRaw(requestParameters: RenamePortfolioOperationRequest, initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<runtime.ApiResponse<void>>;
     /**
-     *
-     * @type {PortfolioSyncInfo}
-     * @memberof Portfolio
+     * This endpoint can be used to rename the display name of a specified portfolio. To restore the original portfolio name, send a rename request with an empty string as the new name. **Note**: This does not change the original portfolio name at your broker.
      */
-    syncInfo: PortfolioSyncInfo;
+    renamePortfolio(requestParameters: RenamePortfolioOperationRequest, initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<void>;
 }
 
 /**
@@ -11873,6 +11986,62 @@ declare function QuoteExpirationToJSON(value?: QuoteExpiration | null): any;
 
 declare function QuoteExpirationToJSONRecursive(value?: QuoteExpiration | null, ignoreParent?: boolean): any;
 
+/**
+ * brokerize
+ * The brokerize API allows clients to implement multi-brokerage with a unified interface. For more information, visit brokerize.com
+ *
+ *
+ *
+ * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
+ * https://openapi-generator.tech
+ * Do not edit the class manually.
+ */
+/**
+ *
+ * @export
+ * @interface RecoveryPhraseItem
+ */
+declare interface RecoveryPhraseItem {
+    /**
+     *
+     * @type {Date}
+     * @memberof RecoveryPhraseItem
+     */
+    createdAt: Date;
+    /**
+     *
+     * @type {Date}
+     * @memberof RecoveryPhraseItem
+     */
+    expiresAt: Date;
+    /**
+     *
+     * @type {string}
+     * @memberof RecoveryPhraseItem
+     */
+    id: string;
+    /**
+     *
+     * @type {Date}
+     * @memberof RecoveryPhraseItem
+     */
+    lastUsedAt: Date;
+    /**
+     *
+     * @type {string}
+     * @memberof RecoveryPhraseItem
+     */
+    name: string;
+}
+
+declare function RecoveryPhraseItemFromJSON(json: any): RecoveryPhraseItem;
+
+declare function RecoveryPhraseItemFromJSONTyped(json: any, ignoreDiscriminator: boolean): RecoveryPhraseItem;
+
+declare function RecoveryPhraseItemToJSON(value?: RecoveryPhraseItem | null): any;
+
+declare function RecoveryPhraseItemToJSONRecursive(value?: RecoveryPhraseItem | null, ignoreParent?: boolean): any;
+
 declare type ReferrerPolicy_2 = "" | "no-referrer" | "no-referrer-when-downgrade" | "origin" | "origin-when-cross-origin" | "same-origin" | "strict-origin" | "strict-origin-when-cross-origin" | "unsafe-url";
 
 export declare type RegisteredUserAuthContextConfiguration = {
@@ -12664,6 +12833,104 @@ declare interface Session {
     syncInfo: SessionSyncInfo;
 }
 
+/**
+ *
+ */
+declare class SessionApi extends runtime.BaseAPI {
+    /**
+     */
+    addSessionRaw(requestParameters: AddSessionRequest, initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<runtime.ApiResponse<LoginResponse>>;
+    /**
+     */
+    addSession(requestParameters: AddSessionRequest, initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<LoginResponse>;
+    /**
+     * If login returns the state `challenge`, the login must be completed by providing a challenge response first.
+     */
+    addSessionCompleteChallengeRaw(requestParameters: AddSessionCompleteChallengeRequest, initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<runtime.ApiResponse<LoginResponseReady>>;
+    /**
+     * If login returns the state `challenge`, the login must be completed by providing a challenge response first.
+     */
+    addSessionCompleteChallenge(requestParameters: AddSessionCompleteChallengeRequest, initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<LoginResponseReady>;
+    /**
+     * Cancel a decoupled operation.  This is deprecated, use the new `CancelDecoupledOperation` instead (which does not require the sessionId anymore).
+     */
+    cancelDecoupledOperationLegacyRaw(requestParameters: CancelDecoupledOperationLegacyRequest, initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<runtime.ApiResponse<void>>;
+    /**
+     * Cancel a decoupled operation.  This is deprecated, use the new `CancelDecoupledOperation` instead (which does not require the sessionId anymore).
+     */
+    cancelDecoupledOperationLegacy(requestParameters: CancelDecoupledOperationLegacyRequest, initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<void>;
+    /**
+     * For brokers with OAuth login processes, this adds the session to the user\'s account after redirects happen. Only the user that is redirected from the broker login in the browser will receive the `code`. This step ensures that the logged-in user at brokerize is actually the one that has gone through the broker OAuth steps.
+     */
+    confirmOAuthRaw(requestParameters: ConfirmOAuthRequest, initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<runtime.ApiResponse<ConfirmOAuthResponse>>;
+    /**
+     * For brokers with OAuth login processes, this adds the session to the user\'s account after redirects happen. Only the user that is redirected from the broker login in the browser will receive the `code`. This step ensures that the logged-in user at brokerize is actually the one that has gone through the broker OAuth steps.
+     */
+    confirmOAuth(requestParameters: ConfirmOAuthRequest, initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<ConfirmOAuthResponse>;
+    /**
+     * If the user chose an auth method from `GetAuthInfo` with the flow `CHALLENGE_RESPONSE`, before enabling session TAN, a challenge must be requested first.
+     */
+    createSessionTanChallengeRaw(requestParameters: CreateSessionTanChallengeRequest, initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<runtime.ApiResponse<Challenge>>;
+    /**
+     * If the user chose an auth method from `GetAuthInfo` with the flow `CHALLENGE_RESPONSE`, before enabling session TAN, a challenge must be requested first.
+     */
+    createSessionTanChallenge(requestParameters: CreateSessionTanChallengeRequest, initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<Challenge>;
+    /**
+     */
+    enableSessionTanRaw(requestParameters: EnableSessionTanRequest, initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<runtime.ApiResponse<EnableSessionTanResponse>>;
+    /**
+     */
+    enableSessionTan(requestParameters: EnableSessionTanRequest, initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<EnableSessionTanResponse>;
+    /**
+     * End Session TAN for the given broker session.  If applicable, the broker may return a message with a confirmation code which can be looked up in the initial activation SMS. If message is present in the response, it should be displayed to the user.
+     */
+    endSessionTanRaw(requestParameters: EndSessionTanRequest, initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<runtime.ApiResponse<EndSessionTanResponse>>;
+    /**
+     * End Session TAN for the given broker session.  If applicable, the broker may return a message with a confirmation code which can be looked up in the initial activation SMS. If message is present in the response, it should be displayed to the user.
+     */
+    endSessionTan(requestParameters: EndSessionTanRequest, initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<EndSessionTanResponse>;
+    /**
+     * Get the status of a decoupled operation.  This is deprecated, use the new `GetDecoupledOperation` instead, which does not require the `sessionId` any more.
+     */
+    getDecoupledOperationStatusLegacyRaw(requestParameters: GetDecoupledOperationStatusLegacyRequest, initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<runtime.ApiResponse<DecoupledOperationStatus>>;
+    /**
+     * Get the status of a decoupled operation.  This is deprecated, use the new `GetDecoupledOperation` instead, which does not require the `sessionId` any more.
+     */
+    getDecoupledOperationStatusLegacy(requestParameters: GetDecoupledOperationStatusLegacyRequest, initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<DecoupledOperationStatus>;
+    /**
+     * Get the currently active broker sessions of the user\'s account.
+     */
+    getSessionsRaw(initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<runtime.ApiResponse<SessionResponse>>;
+    /**
+     * Get the currently active broker sessions of the user\'s account.
+     */
+    getSessions(initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<SessionResponse>;
+    /**
+     * Log out from the given broker session.
+     */
+    logoutSessionRaw(requestParameters: LogoutSessionRequest, initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<runtime.ApiResponse<LogoutOkResponseBody>>;
+    /**
+     * Log out from the given broker session.
+     */
+    logoutSession(requestParameters: LogoutSessionRequest, initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<LogoutOkResponseBody>;
+    /**
+     * For brokers with `isOAuth`, sessions can not be created using `AddSession`. This is how a session can be added for an OAuth-based login process:  1. use `prepareOAuthRedirect` to obtain a URL to redirect to. You can provide a `returnTo` URL which will be redirected to later. Note that a list of allowed URLs has to be configured for the client. 2. redirect the user\'s browser to the `redirectTo` URL 3. after the user has logged in at the broker\'s interface, a redirect to `returnTo` with the URL query parameters `verifysession=1`, `code` and `ticketId` will happen 4. the `returnTo` page must call `confirmOAuth` with the given `ticketId` and `code` to finally add the session to the user\'s account
+     */
+    prepareOAuthRedirectRaw(requestParameters: PrepareOAuthRedirectRequest, initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<runtime.ApiResponse<PrepareOAuthRedirectResponse>>;
+    /**
+     * For brokers with `isOAuth`, sessions can not be created using `AddSession`. This is how a session can be added for an OAuth-based login process:  1. use `prepareOAuthRedirect` to obtain a URL to redirect to. You can provide a `returnTo` URL which will be redirected to later. Note that a list of allowed URLs has to be configured for the client. 2. redirect the user\'s browser to the `redirectTo` URL 3. after the user has logged in at the broker\'s interface, a redirect to `returnTo` with the URL query parameters `verifysession=1`, `code` and `ticketId` will happen 4. the `returnTo` page must call `confirmOAuth` with the given `ticketId` and `code` to finally add the session to the user\'s account
+     */
+    prepareOAuthRedirect(requestParameters: PrepareOAuthRedirectRequest, initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<PrepareOAuthRedirectResponse>;
+    /**
+     * Trigger a background sync process for the given broker session. This means that a sync will be scheduled as soon as possible. All data related to the portfolio (e.g. positions and orders) will be loaded into the brokerize database.
+     */
+    triggerSessionSyncRaw(requestParameters: TriggerSessionSyncRequest, initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<runtime.ApiResponse<OkResponseBody>>;
+    /**
+     * Trigger a background sync process for the given broker session. This means that a sync will be scheduled as soon as possible. All data related to the portfolio (e.g. positions and orders) will be loaded into the brokerize database.
+     */
+    triggerSessionSync(requestParameters: TriggerSessionSyncRequest, initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<OkResponseBody>;
+}
+
 declare function SessionFromJSON(json: any): Session;
 
 declare function SessionFromJSONTyped(json: any, ignoreDiscriminator: boolean): Session;
@@ -14152,6 +14419,14 @@ declare interface UpdateTradeDraftRequest {
  *
  */
 declare class UserApi extends runtime.BaseAPI {
+    /**
+     * Check if the RecoveryPhrase is still valid without obtaining a new token set. This can be used in frontends when users are asked if they still have their RecoveryPhrase.
+     */
+    checkRecoveryPhraseRaw(requestParameters: CheckRecoveryPhraseRequest, initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<runtime.ApiResponse<CheckRecoveryPhrase200Response>>;
+    /**
+     * Check if the RecoveryPhrase is still valid without obtaining a new token set. This can be used in frontends when users are asked if they still have their RecoveryPhrase.
+     */
+    checkRecoveryPhrase(requestParameters: CheckRecoveryPhraseRequest, initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<CheckRecoveryPhrase200Response>;
     /**
      * Create a token for the current user. The token can be used to access resources on behalf of the user.
      */
@@ -14160,6 +14435,38 @@ declare class UserApi extends runtime.BaseAPI {
      * Create a token for the current user. The token can be used to access resources on behalf of the user.
      */
     createAccessToken(requestParameters: CreateAccessTokenRequest, initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<AccessTokenResult>;
+    /**
+     * Create a guest user and return a token which can be used to access resources.  The lifetime of the generated temporary user as well as the returned `access_token` depend on the client configuration. It is usually around 24 hours. For some clients, tokens can be expired earlier based on inactivity.  If the client has configured a longer lifetime for their guest users, a `refresh_token`  is included in the response. This token can be used to renew the `access_token` after it has expired.  The `refresh_token` can be used to obtain a new `access_token` after the original token has expired using the `/user/token` endpoint.
+     */
+    createGuestUserRaw(initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<runtime.ApiResponse<CreateGuestUserResponse>>;
+    /**
+     * Create a guest user and return a token which can be used to access resources.  The lifetime of the generated temporary user as well as the returned `access_token` depend on the client configuration. It is usually around 24 hours. For some clients, tokens can be expired earlier based on inactivity.  If the client has configured a longer lifetime for their guest users, a `refresh_token`  is included in the response. This token can be used to renew the `access_token` after it has expired.  The `refresh_token` can be used to obtain a new `access_token` after the original token has expired using the `/user/token` endpoint.
+     */
+    createGuestUser(initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<CreateGuestUserResponse>;
+    /**
+     * Create a RecoveryPhrase for the current guest user.  The brokerize backend uses RecoveryPhrases instead of email + password registration or similar approaches, which can never be guaranteed to be anonymous.  Users can simply generate a RecoveryPhrase and save it in a password manager, memorize it or write it down in a safe location.  The BIP39 word list known from Bitcoins is used to encode a cryptographically safe random token and allows access to the account later (see endpoint `ObtainTokenFromRecoveryPhrase`).
+     */
+    createRecoveryPhraseRaw(requestParameters: CreateRecoveryPhraseRequest, initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<runtime.ApiResponse<CreateRecoveryPhraseResult>>;
+    /**
+     * Create a RecoveryPhrase for the current guest user.  The brokerize backend uses RecoveryPhrases instead of email + password registration or similar approaches, which can never be guaranteed to be anonymous.  Users can simply generate a RecoveryPhrase and save it in a password manager, memorize it or write it down in a safe location.  The BIP39 word list known from Bitcoins is used to encode a cryptographically safe random token and allows access to the account later (see endpoint `ObtainTokenFromRecoveryPhrase`).
+     */
+    createRecoveryPhrase(requestParameters: CreateRecoveryPhraseRequest, initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<CreateRecoveryPhraseResult>;
+    /**
+     * Delete the current user (only allowed if it is a guest account). Also logs out all active broker sessions attached to the user.
+     */
+    deleteGuestUserRaw(initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<runtime.ApiResponse<void>>;
+    /**
+     * Delete the current user (only allowed if it is a guest account). Also logs out all active broker sessions attached to the user.
+     */
+    deleteGuestUser(initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<void>;
+    /**
+     * Delete the RecoveryPhrase from the account.
+     */
+    deleteRecoveryPhraseRaw(requestParameters: DeleteRecoveryPhraseRequest, initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<runtime.ApiResponse<void>>;
+    /**
+     * Delete the RecoveryPhrase from the account.
+     */
+    deleteRecoveryPhrase(requestParameters: DeleteRecoveryPhraseRequest, initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<void>;
     /**
      */
     getAccessTokensRaw(initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<runtime.ApiResponse<GetAccessTokensResponse>>;
@@ -14174,6 +14481,38 @@ declare class UserApi extends runtime.BaseAPI {
      * Figure out which permissions are available to select from for a new access token.
      */
     getAcessTokenAvailablePermissions(initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<GetAcessTokenAvailablePermissions200Response>;
+    /**
+     * Lists all the recoveryPhrases metadata the user has in their account.
+     */
+    getRecoveryPhrasesRaw(initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<runtime.ApiResponse<GetRecoveryPhrasesResponse>>;
+    /**
+     * Lists all the recoveryPhrases metadata the user has in their account.
+     */
+    getRecoveryPhrases(initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<GetRecoveryPhrasesResponse>;
+    /**
+     * Checks the provided authentication and returns the logged-in user.
+     */
+    getUserRaw(initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<runtime.ApiResponse<GetUserResponse>>;
+    /**
+     * Checks the provided authentication and returns the logged-in user.
+     */
+    getUser(initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<GetUserResponse>;
+    /**
+     * Obtain a new access token using a refresh token as specified in https://datatracker.ietf.org/doc/html/rfc6749#section-4.1.4. If `CreateGuestUser` has provided a `refresh_token`, this endpoint may be used to obtain a new `access_token` after the original token has expired.
+     */
+    obtainTokenRaw(requestParameters: ObtainTokenRequest, initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<runtime.ApiResponse<TokenResponse>>;
+    /**
+     * Obtain a new access token using a refresh token as specified in https://datatracker.ietf.org/doc/html/rfc6749#section-4.1.4. If `CreateGuestUser` has provided a `refresh_token`, this endpoint may be used to obtain a new `access_token` after the original token has expired.
+     */
+    obtainToken(requestParameters: ObtainTokenRequest, initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<TokenResponse>;
+    /**
+     * Obtain a new access and refresh token set by a RecoveryPhrase. The new set also contains a refresh_token etc, so it can then be used just like the tokens obtained from the `ObtainToken` endpoint.  This also creates a new `trading_session`, as RecoveryPhrases never allow access to an existing trading_session.
+     */
+    obtainTokenByRecoveryPhraseRaw(requestParameters: ObtainTokenByRecoveryPhraseRequest, initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<runtime.ApiResponse<TokenResponse>>;
+    /**
+     * Obtain a new access and refresh token set by a RecoveryPhrase. The new set also contains a refresh_token etc, so it can then be used just like the tokens obtained from the `ObtainToken` endpoint.  This also creates a new `trading_session`, as RecoveryPhrases never allow access to an existing trading_session.
+     */
+    obtainTokenByRecoveryPhrase(requestParameters: ObtainTokenByRecoveryPhraseRequest, initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<TokenResponse>;
     /**
      */
     revokeAccessTokenRaw(requestParameters: RevokeAccessTokenRequest, initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<runtime.ApiResponse<void>>;
@@ -14283,6 +14622,20 @@ declare interface WebSocket_2 {
     removeEventListener<K extends keyof WebSocketEventMap_2>(type: K, listener: (this: WebSocket_2, ev: WebSocketEventMap_2[K]) => any, options?: boolean | EventListenerOptions_2): void;
 }
 
+/**
+ *
+ */
+declare class WebsocketApi extends runtime.BaseAPI {
+    /**
+     * Most operations at brokerize have asynchronous effects.  For example, consider the flow of an order: when the user creates an order, it will not immediately appear in order list endpoints, because usually brokers take a few seconds until they are retrievable in those lists. Also, after a while, the order may be executed or cancelled asynchronously by the stock exchange.  A common solution for frontends would be to reload the order list regularly. However data is then either delayed or there will be many more requests than needed.  The brokerize websocket endpoint allows getting updates via web sockets. Generally speaking, clients can subscribe by assigning a subscription id and will then receive updates on that subscription.  In this documentation, ⬆️ denotes messages from the client to the server, whereas messages from server to client are marked with ⬇️.  ## authentication  When using cookies for authorization, the WebSocket connection is authenticated with the HTTP upgrade request.  If token headers are used, the _first_ message from client to server must be:  ``` ⬆️ {     \"cmd\": \"authorize\",     \"idToken\": <string> } ```  In all cases, clients must wait for the welcome message before sending other messages:  ``` ⬇️ { \"cmd\": \"authenticated\" } ```  ## ping  After 1 minute of inactivity of a client, the WebSocket connection will be considered stale and will automatically terminated. To prevent this, a ping message can be sent:  ```  ⬆️ {\"cmd\": \"ping\"} ```  The server also sends this message regularly. If no message has been received on a WebSocket connection for more than 1 minute, it should be terminated by the client.  ```  ⬇️ {\"cmd\": \"ping\"} ```  ## subscriptions  Subscriptions can be used to get invalidate events or updates for selected resources.  ### invalidate subscriptions  Invalidation events can be used for the frontend to know when reload requests via the HTTP endpoints are appropriate. Currently only invalidate events can be subscribed, the actual data must then be reloaded using the HTTP endpoints.  To set up a subscription for an invalidate event, use:  ``` ⬆️ {     \"cmd\": \"subscribe\",     \"type\": \"invalidate\",     \"subscriptionId\": 1,     \"entity: \"brokersessions\" /_* \"positions\" | \"orders\" *_/,     \"portfolioId\": 42 /_* required for \"positions\" or \"orders\" *_/ } ```  If the subscription failed to be set up on the server, an error will be sent for the subscription. This also automatically ends the subscription on the server side:  ``` ⬇️ {     \"subscriptionId\": 1,     \"error\": {         \"message\": \"Could not set up invalidation event due to...\"     } } ```  If an invalid `subscriptionId` is provided (or the subscription id is already in use by the connection), an error like this will be sent:  ``` ⬇️ {     \"error\": {         \"message\": \"Could not add subscription due to invalid subscriptionId\"     } } ```  ⚠️ _the connection will then be terminated immediately_.  If the subscription is sucessfuly set up, whenever an invalidation happens, the server will send a message like this:  ``` ⬇️ {     \"cmd\": \"invalidate\",     \"subscriptionId\": 1 } ```  When that invalidation event is received, the client should reload the data using the corresponding endpoints.  Clients can end their subscription with the `unsubscribe` command:  ``` ⬆️ {     \"cmd\": \"unsubscribe\",     \"subscriptionId\": 1 } ```  ### subscribe to the state of a decoupled operation  For decoupled operations (e.g. authorizing a session TAN using a second factor device), the state of the operation can be subscribed:  ``` ⬆️ {     \"cmd\": \"subscribe\",     \"type\": \"decoupledOperationStatus\",     \"subscriptionId\": 1,     \"sessionId\": string,     \"decoupledOperationId\": string } ```  Error handling as well as unsubscribing works as described for invalidate subscriptions. Example message from the server for updating the state:  ``` ⬇️ {     \"cmd\": \"updateDecoupledOperationStatus\",     \"subscriptionId\": number,     \"state\": <DecoupledOperationStatus> } ```
+     */
+    websocketRaw(initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<runtime.ApiResponse<void>>;
+    /**
+     * Most operations at brokerize have asynchronous effects.  For example, consider the flow of an order: when the user creates an order, it will not immediately appear in order list endpoints, because usually brokers take a few seconds until they are retrievable in those lists. Also, after a while, the order may be executed or cancelled asynchronously by the stock exchange.  A common solution for frontends would be to reload the order list regularly. However data is then either delayed or there will be many more requests than needed.  The brokerize websocket endpoint allows getting updates via web sockets. Generally speaking, clients can subscribe by assigning a subscription id and will then receive updates on that subscription.  In this documentation, ⬆️ denotes messages from the client to the server, whereas messages from server to client are marked with ⬇️.  ## authentication  When using cookies for authorization, the WebSocket connection is authenticated with the HTTP upgrade request.  If token headers are used, the _first_ message from client to server must be:  ``` ⬆️ {     \"cmd\": \"authorize\",     \"idToken\": <string> } ```  In all cases, clients must wait for the welcome message before sending other messages:  ``` ⬇️ { \"cmd\": \"authenticated\" } ```  ## ping  After 1 minute of inactivity of a client, the WebSocket connection will be considered stale and will automatically terminated. To prevent this, a ping message can be sent:  ```  ⬆️ {\"cmd\": \"ping\"} ```  The server also sends this message regularly. If no message has been received on a WebSocket connection for more than 1 minute, it should be terminated by the client.  ```  ⬇️ {\"cmd\": \"ping\"} ```  ## subscriptions  Subscriptions can be used to get invalidate events or updates for selected resources.  ### invalidate subscriptions  Invalidation events can be used for the frontend to know when reload requests via the HTTP endpoints are appropriate. Currently only invalidate events can be subscribed, the actual data must then be reloaded using the HTTP endpoints.  To set up a subscription for an invalidate event, use:  ``` ⬆️ {     \"cmd\": \"subscribe\",     \"type\": \"invalidate\",     \"subscriptionId\": 1,     \"entity: \"brokersessions\" /_* \"positions\" | \"orders\" *_/,     \"portfolioId\": 42 /_* required for \"positions\" or \"orders\" *_/ } ```  If the subscription failed to be set up on the server, an error will be sent for the subscription. This also automatically ends the subscription on the server side:  ``` ⬇️ {     \"subscriptionId\": 1,     \"error\": {         \"message\": \"Could not set up invalidation event due to...\"     } } ```  If an invalid `subscriptionId` is provided (or the subscription id is already in use by the connection), an error like this will be sent:  ``` ⬇️ {     \"error\": {         \"message\": \"Could not add subscription due to invalid subscriptionId\"     } } ```  ⚠️ _the connection will then be terminated immediately_.  If the subscription is sucessfuly set up, whenever an invalidation happens, the server will send a message like this:  ``` ⬇️ {     \"cmd\": \"invalidate\",     \"subscriptionId\": 1 } ```  When that invalidation event is received, the client should reload the data using the corresponding endpoints.  Clients can end their subscription with the `unsubscribe` command:  ``` ⬆️ {     \"cmd\": \"unsubscribe\",     \"subscriptionId\": 1 } ```  ### subscribe to the state of a decoupled operation  For decoupled operations (e.g. authorizing a session TAN using a second factor device), the state of the operation can be subscribed:  ``` ⬆️ {     \"cmd\": \"subscribe\",     \"type\": \"decoupledOperationStatus\",     \"subscriptionId\": 1,     \"sessionId\": string,     \"decoupledOperationId\": string } ```  Error handling as well as unsubscribing works as described for invalidate subscriptions. Example message from the server for updating the state:  ``` ⬇️ {     \"cmd\": \"updateDecoupledOperationStatus\",     \"subscriptionId\": number,     \"state\": <DecoupledOperationStatus> } ```
+     */
+    websocket(initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<void>;
+}
+
 declare type WebSocketAuthenticatedMessage = {
     cmd: "authenticated";
 };