Interactive Brokers
IBKR Client Portal Web API

Streaming WebSocket Data


Interactive Brokers Web API offers the webSocket endpoint to provide streaming data such as market data, live order and pnl updates. Before connecting to websocket you would need to have an authenticated session.

How to Authenticate:

Using Gateway:
To connect using the Gateway follow the Getting Started Instructions, once you receive the message "Client login succeeds" you have completed the authentication step. To gain access to services that require a brokerage session such as market data then send the endpoint https://localhost:5000/v1/api/iserver/accounts

Using OAuth:
To connect using OAuth following the directions on Github. Once the Live Session Token is generated you completed the authentication step. To access services that require a brokerage session you'll need to complete the SSODH Init and Response.

How to connect to Websocket:

The websocket endpoint is available at wss://api.ibkr.com/v1/api/ws, when using Gateway for authentication replace api.ibkr.com with localhost:5000
There are two ways of authorizing yourself with the websocket connection.
  1. Include the cookies from the "set-cookie" headers from previous requests. Most browsers will automatically do this for you, although there are some exception such as Chrome.
  2. Send the "session" value obtained via the /tickle endpoint. Once a websocket without the proper cookies is opened, the websocket will reply with a message saying "waiting for session". This indicates it is waiting for you to send the session value. The session value should be sent as a JSON object, with one key/pair as follows:
Replacing SESSION_VALUE_HERE with the actual session. If the session is valid, the websocket will send a response confirming that you are authenticated.
Access the endpoint https://api.ibkr.com/v1/api/tickle


Websocket Messages:

There are two types of messages: Format for solicated message types: TOPIC+{ARGUMENTS}
Available Topics
Topic Definition
Solicated Message Types
smd+conidex / umd+conidex market data + contract identifier and optional exchange
smh+conid / umh+serverId market data history + server identifier
sor / uor live orders
str / utr trades
spl / upl profit and loss
ech+hb echo + heartbeat
tic ping session
Unsolicated Message Types
system system connection
sts status
ntf notification
blt bulletin


Try the websocket connection here:

Note: Make sure to first launch gateway and authenticate.

wss:// 





Solicited Message Types

Market Data (Level I)

Using the Web API, you can request real time data for trading and analysis. For streaming top of the book (level I) data, the topic is smd+conidex. The conid (contract identifier) uniquely defines an instrument in IBKR's database and is needed for many endpoints. The conidex is formatted as conid or conid@EXCHANGE, if no exchange is specified then SMART is defaulted on contracts that support it. To find the conid for a stock, the endpoint /iserver/secdef/search can be used, for futures /trsrv/futures and for options there is an additional step described here. For the topic: smd+conidex it is required to specify the argument fields. The field value is a JSON Object which are a comma separated list of available tick types as described in the endpoint /iserver/marketdata/snapshot. Additional field values can be added to an existing market data request by resending smd+conidex. To unsubscribe from market data, the topic is umd+conidex.

Format: smd+conidex+{"fields":[]}

Format: umd+conidex+{}


Market Data (History)

For streaming historical data, the topic smh+conid is used. There are also optional params available in Json format. If no params are specified then pass an empty {} param. If a param is specified incorrectly it will be ignored and default returned. For details on the conid review Market Data (Level I) section. Only a max of 5 concurrent request available at a time. To unsubscribe, the topic is umh+serverId whereby use the serverId from the received data.

params definition valid values
String exchange listing exchange valid exchange the contract trades
String period duration of time back {1-30}min, {1-8}h, {1-1000}d, {1-792}w, {1-182}m, {1-15}y
String bar data granularity 1min, 2min, 3min, 5min, 10min, 15min, 30min, 1h, 2h, 3h, 4h, 8h, 1d, 1w, 1m
Boolean outsideRth outside regular trading hours true/false
String source The type of data received
  • "m" or "midpoint" for #MIDPOINT
  • "t" or "trades" for #TRADES
  • "ba" or "bid_ask" for #BID_ASK
  • "b" or "bid" for #BID
  • "a" or "ask" for #ASK
String format historical values returned Can specify multiple separated by forward slash e.g. %o/%c
  • %o - open
  • %c - close
  • %h - high
  • %l - low

Format: smh+conid+{params}

Format: umh+serverId


Live Orders

As long as an order is active, it is possible to retrive it using the Web API. For streaming live orders the topic is sor. Once live orders are requested we will start to relay back when there is an update. To receive all orders for the current day the endpoint /iserver/account/orders?force=false can be used. It is advised to query all orders for the current day first before subscribing to live orders. To unsubscribe from live orders, the topic is uor.

Format: sor+{}

Format: uor+{}

Live Order - Updates: When there is an update to your order only the change to the order is relayed back along with the orderId. Most commonly this would involve status changes and partial fills.

Trades

To review a list of your trades for the current day and six previous days use the topic str. For updates you would only receive new orders as they fill. To unsubscribe from trades, the topic is utr.

Format: str+{}

Format: utr+{}


Profit and Loss

For existing positions it is possible to receive Profit and Loss updates to the Web API using the topic spl. In the payload response the daily profit and loss (dpl) and unrealized profit and loss (upl) are received as a total value for all positions. Updates are relayed back as quickly as once per second but can vary based on market activity. To unsubscribe from profit and loss the topic is upl.

Format: spl+{}

Format: upl{}


Echo

To maintain an active websocket connection the topic ech is used to send a hearbeat with the argument hb. It is advised to send a heatbeat at least once per minute.

Format: ech+hb


Ping Session

To maintain a session for accessing /iserver or /ccp endpoints use the topic tic. It is advised to ping the session at least once per minute. It still requires the UI to send the endpoint /tickle every few minutes or when expires from /sso/validate = 0.

Format: tic



Unsolicited Message Types

System Connection

When initially connecting to websocket the topic system relays back a confirmation with the corresponding username. While the websocket is connecting every 10 seconds there after a heartbeat with corresponding unix time (in millisecond format) is relayed back.

Authentication Status

When connecting to websocket the topic sts will relay back the status of the authentication. Authentication status is already relayed back if there is a change, such as a competing sessions.

Notifications

If there is a brief message regarding trading activity the topic ntf will be sent.

Bulletins

If there is an urgent message concerning exchange issues, system problems and other trading information the topic blt is sent along with the message argument.


© Interactive Brokers 2020