@brokerize/client 1.3.9 → 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;
@@ -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
@@ -4011,215 +4045,13 @@ declare type DecoupledOperationStatus_2 = {
     createdOrderId?: string;
 };
 
-declare function DecoupledOperationStatusFromJSON(json: any): DecoupledOperationStatus;
-
-declare function DecoupledOperationStatusFromJSONTyped(json: any, ignoreDiscriminator: boolean): DecoupledOperationStatus;
-
-declare function DecoupledOperationStatusToJSON(value?: DecoupledOperationStatus | null): any;
-
-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<LogoutOkResponseBody>>;
-    /**
-     * Log out from the given broker session.
-     */
-    logoutSession(requestParameters: LogoutSessionRequest, initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<LogoutOkResponseBody>;
-    /**
-     * 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 function DecoupledOperationStatusFromJSON(json: any): DecoupledOperationStatus;
+
+declare function DecoupledOperationStatusFromJSONTyped(json: any, ignoreDiscriminator: boolean): DecoupledOperationStatus;
+
+declare function DecoupledOperationStatusToJSON(value?: DecoupledOperationStatus | null): any;
+
+declare function DecoupledOperationStatusToJSONRecursive(value?: DecoupledOperationStatus | null, ignoreParent?: boolean): any;
 
 declare const DefaultConfig: Configuration;
 
@@ -4323,6 +4155,10 @@ declare interface DeletePortfolioRequest {
     portfolioId: string;
 }
 
+declare interface DeleteRecoveryPhraseRequest {
+    recoveryPhraseId: string;
+}
+
 declare interface DeleteTradeDraftRequest {
     id: string;
 }
@@ -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;
 }
@@ -8081,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;
@@ -8162,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,
@@ -8191,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,
@@ -8221,9 +8114,15 @@ declare namespace openApiClient {
         GetTradeDraftsRequest,
         UpdateTradeDraftRequest,
         TradeDraftApi,
+        CheckRecoveryPhraseRequest,
         CreateAccessTokenRequest,
+        CreateRecoveryPhraseRequest,
+        DeleteRecoveryPhraseRequest,
+        ObtainTokenRequest,
+        ObtainTokenByRecoveryPhraseRequest,
         RevokeAccessTokenRequest,
         UserApi,
+        WebsocketApi,
         AccessTokenItemFromJSON,
         AccessTokenItemFromJSONTyped,
         AccessTokenItemToJSONRecursive,
@@ -8460,6 +8359,11 @@ declare namespace openApiClient {
         ChangeOrderResponseToJSONRecursive,
         ChangeOrderResponseToJSON,
         ChangeOrderResponse,
+        CheckRecoveryPhrase200ResponseFromJSON,
+        CheckRecoveryPhrase200ResponseFromJSONTyped,
+        CheckRecoveryPhrase200ResponseToJSONRecursive,
+        CheckRecoveryPhrase200ResponseToJSON,
+        CheckRecoveryPhrase200Response,
         ClientConfigFromJSON,
         ClientConfigFromJSONTyped,
         ClientConfigToJSONRecursive,
@@ -8559,6 +8463,16 @@ declare namespace openApiClient {
         CreateOrderParamsToJSONRecursive,
         CreateOrderParamsToJSON,
         CreateOrderParams,
+        CreateRecoveryPhraseParamsFromJSON,
+        CreateRecoveryPhraseParamsFromJSONTyped,
+        CreateRecoveryPhraseParamsToJSONRecursive,
+        CreateRecoveryPhraseParamsToJSON,
+        CreateRecoveryPhraseParams,
+        CreateRecoveryPhraseResultFromJSON,
+        CreateRecoveryPhraseResultFromJSONTyped,
+        CreateRecoveryPhraseResultToJSONRecursive,
+        CreateRecoveryPhraseResultToJSON,
+        CreateRecoveryPhraseResult,
         CreateTanChallengeParamsFromJSON,
         CreateTanChallengeParamsFromJSONTyped,
         CreateTanChallengeParamsToJSONRecursive,
@@ -8962,6 +8876,11 @@ declare namespace openApiClient {
         GetQuoteResponseToJSONRecursive,
         GetQuoteResponseToJSON,
         GetQuoteResponse,
+        GetRecoveryPhrasesResponseFromJSON,
+        GetRecoveryPhrasesResponseFromJSONTyped,
+        GetRecoveryPhrasesResponseToJSONRecursive,
+        GetRecoveryPhrasesResponseToJSON,
+        GetRecoveryPhrasesResponse,
         GetUserResponseFromJSON,
         GetUserResponseFromJSONTyped,
         GetUserResponseToJSONRecursive,
@@ -9045,6 +8964,11 @@ declare namespace openApiClient {
         OAuthLoginFormConfig,
         OAuthLoginFormConfigRedirectStyleEnum,
         OAuthLoginFormConfigRedirectStyleBitpandaEnum,
+        ObtainTokenByRecoveryPhraseParamsFromJSON,
+        ObtainTokenByRecoveryPhraseParamsFromJSONTyped,
+        ObtainTokenByRecoveryPhraseParamsToJSONRecursive,
+        ObtainTokenByRecoveryPhraseParamsToJSON,
+        ObtainTokenByRecoveryPhraseParams,
         OkResponseBodyFromJSON,
         OkResponseBodyFromJSONTyped,
         OkResponseBodyToJSONRecursive,
@@ -9253,6 +9177,11 @@ declare namespace openApiClient {
         QuoteExpirationToJSONRecursive,
         QuoteExpirationToJSON,
         QuoteExpiration,
+        RecoveryPhraseItemFromJSON,
+        RecoveryPhraseItemFromJSONTyped,
+        RecoveryPhraseItemToJSONRecursive,
+        RecoveryPhraseItemToJSON,
+        RecoveryPhraseItem,
         RenamePortfolioRequestFromJSON,
         RenamePortfolioRequestFromJSONTyped,
         RenamePortfolioRequestToJSONRecursive,
@@ -9865,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
@@ -10705,58 +10686,140 @@ declare interface Portfolio {
      */
     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
+     * - 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>>>;
+    /**
      */
-    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>;
 }
 
 /**
@@ -11923,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 = {
@@ -12714,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;
@@ -14202,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.
      */
@@ -14210,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>>;
@@ -14224,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>>;
@@ -14333,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";
 };