Keeping an IBKR API System Running Unattended

The author of this article is not affiliated with Interactive Brokers.

Placing a first order through the TWS API can take an afternoon. Keeping the system running correctly every day, with nobody watching the screen, takes much more work. This article covers what decides whether an automated system gets through a normal week: the daily restart, reconnecting, pacing limits, duplicate orders and reconciliation. None of it depends on what the strategy does.

Plan for the daily restart

TWS and IB Gateway restart once a day by design. The automatic restart setting handles this when nobody is there. About once a week, after IBKR’s weekend server reset, they ask for a fresh login with two factor authentication. A system that expects the connection to stay up forever will fail on its first night.

Treat the restart as a normal event:

• Give your system a quiet period around the restart, so no orders are in flight when the connection drops.
• After the restart, reconnect and wait for the API to say it is ready. Only then carry on.
• If a login needs a person, send an alert that reaches someone. Do not let the system retry quietly until the market opens.
• Stop the computer from going to sleep. A sleeping Windows machine drops the API connection, just like a restart.

IB Gateway is usually the better choice for an unattended system. It is lighter than Trader Workstation, and it has no trading screen that someone can change by accident.

Reconnect without losing your place

Connections also drop outside the restart window, for example after a network problem or a Gateway fault. The TWS API reports this with system messages. Message 1100 means the connection between IBKR and TWS is lost. Messages 1101 and 1102 mean it is back, with market data lost (1101) or kept (1102). Your system should react to each one on purpose:

• On 1100, stop sending new orders and mark every open order and position as unconfirmed.
• On 1102, carry on, but still confirm your state before acting.
• On 1101, subscribe again to the market data your system needs, then confirm your state.

Confirming state is the most important step. After any reconnect, ask IBKR for your open orders, positions and recent executions, and rebuild your picture from what IBKR reports. What your system remembers about the last minute is only a guess. IBKR’s records are the facts.

Stay within the pacing limit

The TWS API limits how many requests a client can send each second. Since early 2025 the limit follows your account’s market data lines. It is half the number of lines, so the default of 100 lines allows 50 requests a second. If the pacing warning is switched on in TWS, going over the limit returns error 100, and repeated breaches end the API session. If it is switched off, TWS slows your requests down by itself. The connection stays up, but orders are quietly delayed.

Historical data requests have their own, stricter limits.

Pacing problems rarely come from the strategy. They usually come from a burst of requests at startup, from asking again and again instead of streaming, and from retry loops that fire as fast as they can. Three habits prevent most of them:

• Send every request through one queue that keeps the rate below the limit.
• Stream market data instead of asking for snapshots in a loop.
• When a request fails, wait before you try again. Do not retry at once.

Never send the same order twice

A duplicated order is the most expensive bug in automated trading. It can happen when a signal is handled twice after a reconnect, or when a request is retried after a timeout that had actually worked. Guard against it in three places:

1. Order IDs. Use the next valid order ID that the API gives you, keep them in order, and never reuse one.
2. Your own reference. Tag every order with your own identifier for the signal behind it, using the order reference field, so you can recognise it in IBKR’s records later.
3. Check before you retry. If you are not sure an order went through, look up open orders and executions for your reference before you send it again.

Reconcile all day, not only at startup

Positions can drift from what your system expects for ordinary reasons: a partial fill, a manual trade in the same account, a corporate action, or an order cancelled by IBKR. Compare your positions and open orders with IBKR’s on a schedule, and decide beforehand what happens when they differ. Usually the right answer is to stop new orders in that instrument and alert a person, rather than fixing the difference automatically.

Know when to stop

Every unattended system needs a kill switch that a person can reach quickly. It also needs limits that stop it without a person: a maximum position, a maximum number of orders in a period, and a daily loss limit set by the trader. When a limit is reached, the system should stop sending orders, cancel open orders if the trader’s rules say so, and tell someone.

Test on paper first

IBKR’s paper trading account is the place to find these problems. Run the system there through several restarts, disconnects and partial fills before it goes near a live account. Paper fills are kinder than real ones, so a clean paper run is the minimum, not proof that live trading will behave the same.

In short

Most of a reliable IBKR system is basic groundwork. Plan for the daily restart. Rebuild your state from IBKR after every reconnect. Stay under the pacing limit. Make duplicate orders impossible. Check positions all day. Keep a kill switch within reach. When these are done, the strategy is the only thing left to think about.