Web API Documentation

Interactive Brokers is merging our web-based API products into a single, comprehensive IBKR Web API, bringing the features of the Client Portal Web API, Digital Account Management, and the Flex Web Service together in a unified interface, accessible by a shared means of authorization and authentication: OAuth 2.0.

Existing endpoints and authentication schemes are not deprecated and will continue to receive features and updates. Rather, we look forward to providing our clients with a new, coordinated set of endpoints exposing the same backend resources. To support this orchestration, the documentation below addresses the functionality of the Client Portal Web API, Digital Account Management, and the Flex Web Service side by side under the Web API umbrella.

Have feedback on our Web API documentation or reference material? Email us at API-Feedback@interactivebrokers.com. We value your suggestions, ideas, and feedback in order to continuously improve our API solutions.

This is an automated feedback inbox and unfortunately, we will not be actively responding from this email. However, if you need a specific answer or additional support, please contact our API Support team or access our general support. Current or prospective institutional clients may also contact their sales representative.

Clients with fully open and funded accounts may use our Web API to interact with their accounts immediately, without any onboarding or approval process.
However, our Web API offers several methods of authentication, some of which do require approval or configuration prior to use.
Additionally, certain sets of features of the Web API, such as Account Registration and Funds and Banking, are not available to all account types and also require configuration by our Sales Engineering team prior to use.

Enterprise and Institutional clients have several methods of authorization and authentication at their disposal.
All methods permit requests to be made directly to Interactive Brokers’ infrastructure.

Please also note that our Web API consists of two broad feature sets, Trading and Account Management.
While the Trading functionality is available to all accountholders, certain Account Management features may not be applicable or available to a given account structure.
Additionally, the Account Management registration and banking functionality requires approval and onboarding by our Sales Engineering team prior to use.
Our Sales Engineering team may be reached at salesengineering@ibkr.com, and a Sales Representative would be happy to provide an introduction.

The list below outlines the general suitability of the available methods for various use-cases. For a more thorough discussion of these access methods, please contact our API Integrations team.

• OAuth2.0 (beta)
  • Supports first-party (accessing one’s own accounts) and third-party (accessing the accounts of unaffiliated IB clients with their authorization) usage
  • Offers access to account management and trading features
• OAuth1.0a
  • Supports first-party (accessing one’s own accounts) and third-party (accessing the accounts of unaffiliated IB clients with their authorization) usage
  • Offers access to trading features only
• SSO
  • Available to Financial Advisors and Introducing Brokers
  • Supports the development of alternative UIs specifically for clients under your management
  • Offers access to account management and trading features

Interactive Brokers identifies third-party developers as vendors of software that would interact with IB client accounts to which the vendor has no formal relationship or access within IB. This is in contrast to an advisor or introducing broker who maintains an account structure with IB and formally manages client accounts.

Third-party vendors may currently only seek approval for the use of OAuth1.0a.

Third-party vendors must be receive Compliance approval for their product offerings before integration can proceed. The third-party approval process begins with our third-party onboarding form, which can be submitted to webapionboarding@interactivebrokers.com. Please note that vendors are expected to have an established business entity and a public presence online with material describing their offering. Proof of concept builds to demonstrate intended functionality are strongly encouraged as well.

The onboarding process typically proceeds as follows:

1. Our onboarding team conducts the initial screening. Estimated time to complete this step is 2-3 weeks. If our onboarding team is able to proceed with your request for approval, they will send your application to our Compliance team for review.
2. IBKR Compliance conducts an enhanced due diligence review on all third-party applicants, followed by a three-tier approval process. Estimated time to complete Compliance-related reviews and tasks is 3-6 weeks.
3. If Compliance grants approval, our Legal team will generate a Web API agreement which will be relayed to you for review and signature. In parallel, our third-party onboarding team will ask you to provide public keys and a callback URL in support of the configuration of your OAuth1.0a consumer. Detailed instructions for this process will be provided once this stage is reached. Estimated time for IB complete our portions of the aforementioned process is 3-5 weeks.

The above timelines are estimates and can vary. We recommend providing as much information as possible up front. Not doing so can extend timelines.

During the enhanced due diligence reviews conducted by our Compliance teams, they will expect vendors to have a completed website with finalized details of the product offering. This typically includes a clear user workflow for all components and descriptions of their functionality and capabilities.

Should Compliance approval be reached for your product offering, any significant changes to the offering following approved (such as the addition of trading functionality) would require additional review and approval from our Compliance teams before being offered to IBKR clients.

Please be aware we expect third-party vendors offering automated trading solutions to hold applicable registration with financial authorities in all regions they plan to service, unless the vendor is able to provide support (i.e., a legal opinion) as to why the proposed service would not require registration in a given location. Additionally, the offering will need to be reviewed and approved by Compliance teams in all regions in which you intend to serve IBKR clients.

Interactive Brokers maintains regularly scheduled maintenance for all users of the Client Portal API. The system reset time is unique from that of the standard Trader Workstation connection. Clients will see disconnects at midnight of their connecting region.

Interactive Brokers currently enforces a global request rate limit of 10 requests per second. In addition, some endpoints are also subject to their own pacing limits as described in the table below.

When a limit is exceeded, the Web API will return a 429 Too Many Requests status code. Violator IP addresses are put in a penalty box for 10 minutes. After this period, the IP address is removed from the penalty box. Repeat violator IP addresses may be permanently blocked until the issue is resolved.

Access to Trading functionality in the Web API entails the creation of a trading-enabled brokerage session.

A brokerage session is associated with an IB username (your credentials), which in turn has trading permissions for one or more accounts (the actual pools of equity).
A single username can only have one brokerage session active at a time across all IB platforms.
Permissions for trading in general, for specific asset classes, market data subscriptions (and thus access to the subscribed feeds), etc. are carried by IB usernames, not the underlying accounts.
Hence references to brokerage sessions refer to a logged-in username that is in contact with IBKR’s backend trading infrastructure.

Though Interactive Brokers permits a username only one brokerage session at any given time, some of the Web API’s Trading functionality is accessible without a brokerage session.
This allows a username’s active brokerage session to continue elsewhere undisturbed.
We typically refer to these non-brokerage features as the “read-only” subset of the Trading portion of the Web API.
Examples of read-only features include retrieval of portfolio data and certain instrument search tools.

When trading with the Web API, sessions can therefore be thought of as two-tiered:

1. An “outer” prerequisite “read-only session” that is required to be active/valid in order to make any CP Web API request, though by itself it only permits access to non-/iserver endpoints.
2. The “brokerage session”, established after the read-only, that permits access to trading, consumption of market data, and all other functionality behind /iserver endpoints.

In order to retrieve top-of-book, depth-of-book, or historical market data from the Web API, the following must be available:

• Username with relevant live market data subscriptions and permission to trade the desired instruments
• Authorized Web API session
• Brokerage session (access to IServer endpoints)

Top-of-book snapshots deliver up-to-date market data values sourced from the same streams as are displayed in Trader Workstation’s watchlists.

Values needed:

• Contract ID (“conid”) for the desired instrument(s)
• Tag identifiers for the desired data points (“fields”)

A GET request to the /iserver/marketdata/snapshot [ref↗] endpoint is used to retrieve a snapshot of top-of-book market data for one or more instruments.

This endpoint takes two required query parameters:

• conids: A comma-separated list of instrument conids
• fields: A comma-separated list of field tags. A comprehensive list of available tags can be found in our Reference material.

In order for the desired data to be available for snapshotting on request, a “pre-flight” request must be made to IServer to begin its consumption of the instrument’s live data stream.
This initial request will not deliver any data, but rather makes the stream available for future snapshot requests.
Snapshot market data is not cached and is extracted directly from these open streams.

This pre-flight request should include in its fields parameter all of the tags desired in the future:

GET https://api.ibkr.com/v1/api/iserver/marketdata/snapshot?conids=265598,8314&fields=31,7059,84,88,86,85

If this is the first time you’ve made a /iserver/marketdata/snapshot request for conids 265598 and 8314, you will not receive data in response. Instead you’ll see the requested conids returned, indicating that IServer is now streaming data for these instruments.

[{"conid": 265598, "conidEx": "265598"}, {'conid': 8314, 'conidEx': '8314'}]

Once a pre-flight request has been made for a given conid, all requested fields will be delivered with all future responses; future snapshot requests do not need to repeat the desired fields:

GET https://api.ibkr.com/v1/api/iserver/marketdata/snapshot?conids=265598,8314

Returns:

[{"31": "168.42",
  "6119": "q1",
  "6509": "RpB",
  "7059": "100",
  "84": "168.41",
  "85": "600",
  "86": "168.42",
  "88": "1,300",
  "_updated": 1712596911593,
  "conid": 265598,
  "conidEx": "265598",
  "server_id": "q1"},
 {"31": "189.60",
  "6119": "q2",
  "6509": "RpB",
  "7059": "100",
  "84": "189.56",
  "85": "500",
  "86": "189.61",
  "88": "200",
  "_updated": 1712596911593,
  "conid": 8314,
  "conidEx": "8314",
  "server_id": "q2"}]

Certain fields that update less frequently, particularly those that are computed on an interval, maybe not be delivered immediately, and instead will be returned when updated.

To open a stream for live, top-of-book market data for an instrument, we write the following message to the websocket:

smd+conid+{"fields":["field_1","field_2","field_n","field_n+1"]}

The values in the fields array are the same field tags used in the HTTP request to /iserver/marketdata/snapshot.
These field tag values must be passed as JSON strings, wrapped in double-quotes.

If successful, we will begin to receive response messages on websocket in the following format:

{
  "server_id":"server_id",
  "conidEx":"conidEx",
  "conid":conid,
  "_updated":_updated,
  "6119":"serverId",
  "field_1":field_1,
  "field_2":field_2,
  "field_n":field_n, 
  "field_n+1":field_n+1,
  "6509":"RB",
  "topic":"smd+conid"
}

We may cancel a top-of-book stream on the websocket by sending:

umd+conId+{}

All order-related functionality described below assumes the following are available:

• Username with relevant relevant trading permissions
• Authorized Web API session
• Brokerage session (access to IServer endpoints)
• Account ID of an account that can receive the order, and for which your username has trading permissions

The following workflow describes the submission of a new order ticket.

Values needed:

• Contract ID (“conid”) for the desired instrument(s)
• Your desired order handling instructions

A POST request to the /iserver/account/{accountId}/orders endpoint is used to submit a new order ticket to the account referenced by {accountId} in the path.

This endpoint takes one required path parameter:

• accountId: The account ID of the account to which the order will be placed.

This endpoint also requires a JSON body. The specific keys required to successfully submit a given order ticket will vary depending on a variety of factors, including order type. More information on the construction of order tickets can be found on our Order Types page.

However, at a minimum, any new order ticket submitted via the Web API will require in its body:

• conid: The instrument’s conid
• orderType: The Order Type of the new order ticket
• side: The side of the order being placed (e.g., “BUY” or “SELL”)
• tif: Time in force, the duration for which the order will work.
• quantity: A number of units of the instrument

Please consult our Reference Material for a list of all JSON keys available when submitting new order tickets.

Suppose we have trading permissions for account DU123456.
We’d like submit a new order to this account to buy 100 shares of AAPL, with a limit price of USD 165, to work for the remainder of today’s regular trading hours (an unmodified “day” order).

First we must have obtained IB’s conid for AAPL stock, trading in the US in USD, which is 265598.

We must also know how to represent our desired handling instructions to the Web API:

• A buy order is "side":"BUY"
• A quantity of 100 shares is "quantity":100
• A limit order is "orderType":"LMT"
• A limit price of USD 165 is "price":165
• A day order is "tif":"DAY"
• And finally, AAPL’s conid is "conid":265598

Note that both the keys and values above are case-sensitive.
Care must also be taken to ensure the correct JSON data types are used, as detailed in our Reference Material.

We may then construct the following request:

POST https://api.ibkr.com/v1/api/iserver/account/DU123456/orders

[
  {
    "conid": 265598,
    "side": "BUY",
    "orderType": "LMT",
    "price": 165,
    "quantity": 100,
    "tif": "DAY"
  }
]

Note also that the body of this POST request requires a JSON array containing the order ticket object.
This array is used to submit order brackets, as detailed below.
For now, we will submit only a single order ticket by way of a single object element in this array.

If we are successful in submitting our order, we will receive a response that includes an order_id value that can be used to keep track of the status of the order, as well as an indication of its current status at the time of submission:

{
  "order_id": "987654",
  "order_status": "Submitted",
  "encrypt_message": "1"
}

In some cases the response to an order submission request might not deliver an acknowledgment.
Instead, it might contain an “order reply message” — essentially a notice — which must be confirmed via a second request before our order ticket can go to work.

The receipt of such an “order reply message” does not indicate that the order is rejected or otherwise encountered a problem.
Rather, IB requires explicit confirmation of some element of the order ticket, or some aspect of our subsequent handling, before we can seek the order’s execution.

Very often these messages pertain to precautionary settings that are client-configurable for a given username — effectively “fat finger” protections that you can adjust or remove if desired:

[
  {
    "id": "07a13a5a-4a48-44a5-bb25-5ab37b79186c",
    "message": [
      "The following order \"BUY 100 AAPL NASDAQ.NMS @ 165.0\" price exceeds \nthe Percentage constraint of 3%.\nAre you sure you want to submit this order?"
    ],
    "isSuppressed": false,
    "messageIds": [
      "o163"
    ]
  }
]

Aside from the content of the message, there are two important values delivered in such an “order reply” response.

First, we have an id, which uniquely identifies the emitted message.
Via the /iserver/reply/{messageId} endpoint, we can use this id value to dismiss the message and put our order to work:

POST https://api.ibkr.com/v1/api/iserver/reply/a12b34c5-d678-9e012f-3456-7a890b12cd3e

{"confirmed":true}

The above request requires a JSON body containing {"confirmed":true}, which is an instruction to IB that the message has been received, and you would like to continue with your order.

Provided the order can be accepted and put to work, the response to your /iserver/reply/{messageId} request will be an order acknowledgement response as shown above:

{
  "order_id": "1234567890",
  "order_status": "Submitted",
  "encrypt_message": "1"
}

Another important value (or set of values) to capture from order message response is messageIds, as in "messageIds": ["o163"] above.

These messageIds strings categorize varieties of order reply messages.
You can use these IDs to suppress certain types of order reply messages for the remainder of your username’s current Web API brokerage session.

Please see the Suppressing Order Reply Messages section for more detail.

The following response to an order ticket submission indicates that we must confirm some aspect of our order ticket before it will be accepted:

[
  {
    "id": "07a13a5a-4a48-44a5-bb25-5ab37b79186c",
    "message": [
      "The following order \"BUY 100 AAPL NASDAQ.NMS @ 165.0\" price exceeds \nthe Percentage constraint of 3%.\nAre you sure you want to submit this order?"
    ],
    "isSuppressed": false,
    "messageIds": [
      "o163"
    ]
  }
]

We call these messages “order reply messages”.

The "messageIds" array contains identifiers that categorize the type of order reply message we’ve received.
In this case, we’ve received "messageIds": ["o163"].

Certain types of order reply messages may be suppressed for the duration of your username’s current Web API brokerage session.

When a category of order reply messages is suppressed, you will no longer be sent order reply message responses requiring confirmation.
Instead, a valid order ticket will be accepted and acknowledged immediately. Invalid order tickets will be rejected.

The /iserver/questions/suppress endpoint provides this suppression mechanism.
You may POST an array of messageIDs to suppress those order message types for the remainder of the Web API brokerage session:

POST https://api.ibkr.com/v1/api/iserver/questions/suppress

{"messageIds": ["o163"]}

The response will confirm their suppression:

{"status": "submitted"}

You do not need to have received a given messageID value previously in order to suppress it.
We recommend that you submit this list of messages to be suppressed at the beginning of your brokerage session, prior to conducting any trading.
If you would like to suppress a new type of message while trading, please resend the complete array of messageIds.

You may also undo all suppression of messages within your current brokerage session:

POST https://api.ibkr.com/v1/api/iserver/questions/suppress/reset

And the response will confirm the restoration of delivery of all messages generated during order submission:

{"status": "submitted"}

Documentation coming soon.

Documentation coming soon.

The following example describes the submission of a request to modify an existing, unfilled order ticket.

Values needed:

• All previously submitted order handling instructions, including the instrument’s conid
• The orderId of the order ticket to be modified

A POST request to the /iserver/account/{accountId}/order/{orderId} endpoint is used to submit a request to modify the order ticket referenced by {orderId} in the account {accountId}.

This endpoint takes two required path parameters:

• accountId: The account ID to which the unfilled order belongs.
• orderId: The orderId of the order ticket to be modified.

This endpoint also requires a JSON body. This JSON body must be a single JSON object (note: not an array) containing all of the attributes and handling instructions of the original order ticket.
All JSON keys from the initial order submission must be present, and all JSON values must also be the same, except for the value(s) you seek to modify.

Note that order modification can be subject to different sets of market rules compared to new order submission. Our /iserver/secdef/rules endpoint can be used to inspect the ruleset enforced on a modification.

Suppose we have an active, unfilled order with orderId 987654 belonging to account DU123456, originally submitted with the following handling instructions:

[
  {
    "conid": 265598,
    "side": "BUY",
    "orderType": "LMT",
    "price": 165,
    "quantity": 100,
    "tif": "DAY"
  }
]

We’d like to change the limit price of this order from 165 to 170.

To do so, we send the following request:

POST https://api.ibkr.com/v1/api/iserver/account/DU123456/order/987654

{
  "conid": 265598,
  "side": "BUY",
  "orderType": "LMT",
  "price": 170,
  "quantity": 100,
  "tif": "DAY"
}

Note first that order modification addresses only a single order per request.
Therefore, this request does not use a JSON array as a container for the modified order ticket object.
Instead, the modified order ticket object is the entirety of the request body.

Additionally, we must ensure that all other attributes of the order ticket, aside from the value being altered, are identical to the current, pre-modification attributes of the existing order ticket.
While it should be sufficient to store the contents of a successfully submitted new order ticket client-side, we may also inspect the contents of an existing order ticket with the Order Status endpoint, /iserver/account/{accountId}/order/status/{orderId}.

A successful order modification will return a response similar to a successful new order submission:

{
  "order_id": "987654",
  "order_status": "Submitted",
  "encrypt_message": "1"
}

Alternatively, we may also receive an order reply message, as described above.

Values needed:

• The orderId of the order ticket to be canceled

A DELETE request to the /iserver/account/{accountId}/order/{orderId} endpoint is used to submit a request cancel the order ticket referenced by {orderId} in the account {accountId}.

This endpoint takes two required path parameters:

• accountId: The account ID to which the unfilled order belongs.
• orderId: The orderId of the order ticket to be modified.

The DELETE method of this endpoint does not accept any JSON body.

To cancel an order with orderId 987654, we send the following request:

DELETE https://api.ibkr.com/v1/api/iserver/account/DU123456/order/987654

A successful request for order cancellation returns a message that our request has been received:

{
    "msg": "Request was submitted",
    "order_id": 987654,
    "conid": 265598,
    "account": "DU123456"
}

Note that the above response indicates our request to cancel order 987654 was received, but not that the order ticket itself has been canceled. It is possible that an order working at an exchange or other external venue cannot be canceled, for instance, as a result of auction-related deadlines.

Documentation coming soon.

Combo or spread orders may be submitted using the same /iserver/account/{accountId}/orders endpoint described above.
In the case of combo orders, we must include the conidex field in our request body instead of conid. The conidex field is a string representation of our combo order’s composition.

A combo order’s conidex value takes the following form: {spread_conid};;;{leg_conid1}/{ratio},{leg_conid2}/{ratio}

The spread_conid value is a unique identifier associated with the currency in which the combo’s legs trade.
For US Stock Combos, the spread_conid value will the the USD conid integer by itself. For combo orders in all other currencies, spread_conid takes the form spread_conid@exchange.

Available currency spread conids:

The spread_conid is followed by three semicolons, and then the first leg’s leg_conid. Next, a forward slash /, followed by the ratio of the preceding leg.

The ratio value conveys two pieces of information. The first is the side, buy or sell, of the leg, indicated by the sign of the ratio value, positive or negative. A positive ratio integer indicates a Buy, while a negative ratio integer represents a Sell. The second piece of information is the relative size of the leg in the combo, indicated by the integer magnitude itself. This magnitude acts as a multiplier when placing an order for the overall combo instrument.

Additional legs are separated by commas, and follow the same pattern as above: {leg_conid}/{ratio}.

Please be aware that the number of legs permissible in a single combo order varies by exchange.

Combo orders are priced by summing the per-leg prices, taking into account the side of each leg:
Combo order price = [({Cost of Leg 1} * {The ratio of Leg 1}) + ({Cost of Leg n} * {Ratio of Leg n}) + ({Cost of Leg n+1} * {Ratio of Leg n+1})]

The /iserver/account/orders endpoint is used to retrieve the status of all recently open orders in a given account. This includes orders currently working as well as those cancelled or filled within the same brokerage session.

Example request:

GET https://api.ibkr.com/v1/api/iserver/account/orders?filters=filled&force=true&accountId=U1234567

Successful response:

{
  "orders": [
    {
      "acct": "U1234567",
      "conidex": "265598",
      "conid": 265598,
      "account": "U1234567",
      "orderId": 1234568790,
      "cashCcy": "USD",
      "sizeAndFills": "5",
      "orderDesc": "Sold 5 Market, GTC",
      "description1": "AAPL",
      "ticker": "AAPL",
      "secType": "STK",
      "listingExchange": "NASDAQ.NMS",
      "remainingQuantity": 0.0,
      "filledQuantity": 5.0,
      "totalSize": 5.0,
      "companyName": "APPLE INC",
      "status": "Filled",
      "order_ccp_status": "Filled",
      "avgPrice": "192.26",
      "origOrderType": "MARKET",
      "supportsTaxOpt": "1",
      "lastExecutionTime": "231211180049",
      "orderType": "Market",
      "bgColor": "#FFFFFF",
      "fgColor": "#000000",
      "order_ref": "Order123",
      "timeInForce": "GTC",
      "lastExecutionTime_r": 1702317649000,
      "side": "SELL"
    }
  ],
  "snapshot": true
}

Documentation coming soon.

In non-tiered account structures, the /portfolio/accounts endpoint returns a list of accounts for which the user can view position and account information. This endpoint must be called prior to calling other /portfolio endpoints for those accounts. For querying a list of accounts which the user can trade, see /iserver/accounts. For a list of subaccounts in tiered account structures (e.g. financial advisor or ibroker accounts) see /portfolio/subaccounts.

Example request:
GET https://api.ibkr.com/v1/api/portfolio/accounts

Successful response:

[
  {
    "id": "U1234567",
    "PrepaidCrypto-Z": false,
    "PrepaidCrypto-P": false,
    "brokerageAccess": true,
    "accountId": "U1234567",
    "accountVan": "U1234567",
    "accountTitle": "",
    "displayName": "U1234567",
    "accountAlias": null,
    "accountStatus": 1644814800000,
    "currency": "USD",
    "type": "DEMO",
    "tradingType": "PMRGN",
    "businessType": "IB_PROSERVE",
    "ibEntity": "IBLLC-US",
    "faclient": false,
    "clearingStatus": "O",
    "covestor": false,
    "noClientTrading": false,
    "trackVirtualFXPortfolio": true,
    "parent": {
      "mmc": [],
      "accountId": "",
      "isMParent": false,
      "isMChild": false,
      "isMultiplex": false
    },
    "desc": "U1234567"
  }
]

In multi-level account structures (such as Financial Advisor and IBroker accounts), the /portfolio/subaccounts endpoint returns a list of up to 100 subaccounts for which the user can view position and account-related information. This endpoint must be called prior to calling other /portfolio endpoints for those subaccounts. If you have more than 100 subaccounts use /portfolio/subaccounts2. To query a list of accounts the user can trade, see /iserver/accounts.

Example request:
GET https://api.ibkr.com/v1/api/portfolio/subaccounts

Successful response:

[
  {
    "id": "U1234567",
    "PrepaidCrypto-Z": false,
    "PrepaidCrypto-P": false,
    "brokerageAccess": false,
    "accountId": "U1234567",
    "accountVan": "U1234567",
    "accountTitle": "",
    "displayName": "U1234567",
    "accountAlias": null,
    "accountStatus": 1644814800000,
    "currency": "USD",
    "type": "DEMO",
    "tradingType": "PMRGN",
    "businessType": "IB_PROSERVE",
    "ibEntity": "IBLLC-US",
    "faclient": false,
    "clearingStatus": "O",
    "covestor": false,
    "noClientTrading": false,
    "trackVirtualFXPortfolio": true,
    "parent": {
      "mmc": [],
      "accountId": "",
      "isMParent": false,
      "isMChild": false,
      "isMultiplex": false
    },
    "desc": "U1234567"
  }
]

The /portfolio/{accountId}/ledger endpoint delivers information regarding cash balances, organized by currency.

GET https://api.ibkr.com/v1/api/portfolio/{accountId}/ledger

{
  "USD": {
    "commoditymarketvalue": 0.0,
    "futuremarketvalue": -1051.0,
    "settledcash": 214716688.0,
    "exchangerate": 1,
    "sessionid": 1,
    "cashbalance": 214716688.0,
    "corporatebondsmarketvalue": 0.0,
    "warrantsmarketvalue": 0.0,
    "netliquidationvalue": 215335840.0,
    "interest": 305569.94,
    "unrealizedpnl": 39695.82,
    "stockmarketvalue": 314123.88,
    "moneyfunds": 0.0,
    "currency": "USD",
    "realizedpnl": 0.0,
    "funds": 0.0,
    "acctcode": "U1234567",
    "issueroptionsmarketvalue": 0.0,
    "key": "LedgerList",
    "timestamp": 1702582321,
    "severity": 0,
    "stockoptionmarketvalue": -2.88,
    "futuresonlypnl": -1051.0,
    "tbondsmarketvalue": 0.0,
    "futureoptionmarketvalue": 0.0,
    "cashbalancefxsegment": 0.0,
    "secondkey": "USD",
    "tbillsmarketvalue": 0.0,
    "endofbundle": 1,
    "dividends": 0.0
  },
  "BASE": {
    "commoditymarketvalue": 0.0,
    "futuremarketvalue": -1051.0,
    "settledcash": 215100080.0,
    "exchangerate": 1,
    "sessionid": 1,
    "cashbalance": 215100080.0,
    "corporatebondsmarketvalue": 0.0,
    "warrantsmarketvalue": 0.0,
    "netliquidationvalue": 215721776.0,
    "interest": 305866.88,
    "unrealizedpnl": 39907.37,
    "stockmarketvalue": 316365.38,
    "moneyfunds": 0.0,
    "currency": "BASE",
    "realizedpnl": 0.0,
    "funds": 0.0,
    "acctcode": "U1234567",
    "issueroptionsmarketvalue": 0.0,
    "key": "LedgerList",
    "timestamp": 1702582321,
    "severity": 0,
    "stockoptionmarketvalue": -2.88,
    "futuresonlypnl": -1051.0,
    "tbondsmarketvalue": 0.0,
    "futureoptionmarketvalue": 0.0,
    "cashbalancefxsegment": 0.0,
    "secondkey": "BASE",
    "tbillsmarketvalue": 0.0,
    "dividends": 0.0
  }
}