@brokerize/client 1.0.1

package/dist/swagger/apis/DefaultApi.d.ts

@@ -0,0 +1,228 @@
+/**
+ * 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.
+ */
+import * as runtime from "../runtime";
+import { Challenge, CreateGuestUserResponse, CreateTanChallengeParams, DecoupledOperationStatus, EnableSessionTanParams, EnableSessionTanResponse, EndSessionTanResponse, GetAuthInfoResponse, GetOrderResponse, GetPortfolioOrdersResponse, GetPortfolioPositionsResponse, GetPortfolioQuotesResponse, GetUserResponse, ObtainToken200Response, OkResponseBody, PortfoliosResponse, RenamePortfolioRequest, SessionResponse } from "../models";
+export interface CancelDecoupledOperationRequest {
+    sessionId: string;
+    decoupledOperationId: string;
+}
+export interface CreateSessionTanChallengeRequest {
+    sessionId: string;
+    createTanChallengeParams: CreateTanChallengeParams;
+}
+export interface DeletePortfolioRequest {
+    portfolioId: string;
+}
+export interface EnableSessionTanRequest {
+    sessionId: string;
+    enableSessionTanParams: EnableSessionTanParams;
+}
+export interface EndSessionTanRequest {
+    sessionId: string;
+}
+export interface GetAuthInfoRequest {
+    portfolioId: string;
+}
+export interface GetDecoupledOperationStatusRequest {
+    sessionId: string;
+    decoupledOperationId: string;
+}
+export interface GetOrderRequest {
+    id: string;
+}
+export interface GetPortfolioOrdersRequest {
+    portfolioId: string;
+    take?: number;
+    skip?: number;
+    search?: string;
+    statuses?: string;
+    orderBy?: string;
+    isin?: string;
+    wkn?: string;
+    sinoTicker?: string;
+    usTicker?: string;
+    cryptoCode?: string;
+}
+export interface GetPortfolioPositionsRequest {
+    portfolioId: string;
+}
+export interface GetPortfolioQuotesRequest {
+    portfolioId: string;
+}
+export interface LogoutSessionRequest {
+    sessionId: string;
+}
+export interface ObtainTokenRequest {
+    grantType: string;
+    refreshToken: string;
+}
+export interface RenamePortfolioOperationRequest {
+    portfolioId: string;
+    renamePortfolioRequest: RenamePortfolioRequest;
+}
+export interface TriggerSessionSyncRequest {
+    sessionId: string;
+}
+/**
+ *
+ */
+export 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>;
+    /**
+     * 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>;
+    /**
+     */
+    getOrderRaw(requestParameters: GetOrderRequest, initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<runtime.ApiResponse<GetOrderResponse>>;
+    /**
+     */
+    getOrder(requestParameters: GetOrderRequest, initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<GetOrderResponse>;
+    /**
+     */
+    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>;
+    /**
+     */
+    getPortfoliosRaw(initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<runtime.ApiResponse<PortfoliosResponse>>;
+    /**
+     */
+    getPortfolios(initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<PortfoliosResponse>;
+    /**
+     * Get the currently active broker sessions of the user\'s account.
+     */
+    getSessionsRaw(initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<runtime.ApiResponse<SessionResponse>>;
+    /**
+     * Get the currently active broker sessions of the user\'s account.
+     */
+    getSessions(initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<SessionResponse>;
+    /**
+     * Checks the provided authentication and returns the logged-in user.
+     */
+    getUserRaw(initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<runtime.ApiResponse<GetUserResponse>>;
+    /**
+     * Checks the provided authentication and returns the logged-in user.
+     */
+    getUser(initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<GetUserResponse>;
+    /**
+     * Log out from the given broker session.
+     */
+    logoutSessionRaw(requestParameters: LogoutSessionRequest, initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<runtime.ApiResponse<OkResponseBody>>;
+    /**
+     * Log out from the given broker session.
+     */
+    logoutSession(requestParameters: LogoutSessionRequest, initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<OkResponseBody>;
+    /**
+     * Obtain a new access token using a refresh token as specified in https://datatracker.ietf.org/doc/html/rfc6749#section-4.1.4. If `CreateGuestUser` has provided a `refresh_token`, this endpoint may be used to obtain a new `access_token` after the original token has expired.
+     */
+    obtainTokenRaw(requestParameters: ObtainTokenRequest, initOverrides?: RequestInit | runtime.InitOverideFunction): Promise<runtime.ApiResponse<ObtainToken200Response>>;
+    /**
+     * 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<ObtainToken200Response>;
+    /**
+     * 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>;
+}