IBKR Web API vs TWS API: login, restarts and who can use it

Short answer: IBKR Web API vs TWS API comes down to what must stay running: the TWS API is a socket connection to a logged-in TWS or IB Gateway, while the Web API is REST and WebSocket, reached by retail accounts through the local Client Portal Gateway. Neither offers an individual account unattended login, but as read on 5 November 2026 the TWS route needs a manual login about weekly with auto-restart and the gateway route daily. A hosted product acting on other people's accounts through the Web API needs OAuth approval, which individual accounts cannot get.

Both APIs reach the same account, so the choice is about operations rather than features: who logs in, how often, and on which machine. This page compares them from IBKR's own documents, read on 5 November 2026. The documentation was heavily reorganized in October 2026, so a map of where it now lives is at the end, along with the points where its pages disagree. Which credentials you need and what they cost is covered in the Interactive Brokers API key guide. No IBKR account was available, so nothing here ran against a real login.

No broker is recommended or ranked here, and rules depend on your country and account type. For readers in Turkey, separate rules apply to leveraged FX with foreign firms: the Capital Markets Board said on 23 February 2023 (opens in a new tab) that residents may trade leveraged products only through firms it has authorized (Law No. 6362 (opens in a new tab) Articles 99(4) and 109(2)). Automated trading can lose money.

IBKR Client Portal API vs TWS API: the comparison

For a single account the deciding rows are login, restarts and what has to run on your machine; the rest rarely changes the answer.

Python readers should also know that IBKR added a synchronous wrapper in TWS API 10.40, which removes the callback style but not the need for a running TWS or Gateway. Setup and code are in Interactive Brokers API Python.

IBKR Web API authentication: three methods, one open to individuals

Individual accounts use the Client Portal Gateway; OAuth 1.0a and OAuth 2.0 are for institutions and approved vendors, and they call https://api.ibkr.com directly with no gateway.

Once logged in, a session has two tiers. A read-only session (opens in a new tab) reaches non-/iserver endpoints such as portfolio data and leaves a TWS session undisturbed. Market data and orders need a brokerage session, with a set start-up order that IBKR describes in prose. This is that order in code. It ran on 5 November 2026 (Python 3.11, requests) against a local stub standing in for the gateway, not against IBKR software, so it shows the sequence and not real responses.

import os, time
import requests, urllib3

urllib3.disable_warnings()                 # the gateway's certificate is self-signed
BASE = os.environ.get("CPGW", "https://localhost:5000") + "/v1/api"
s = requests.Session()
s.verify = False                           # acceptable only for this localhost hop
s.headers["User-Agent"] = "my-tool/1.0"    # IBKR asks for one on every request

def start_brokerage_session():
    """Run after the human has logged in through the browser on this machine."""
    s.post(f"{BASE}/iserver/auth/ssodh/init",
           json={"publish": True, "compete": True},  # compete disconnects other sessions
           timeout=15).raise_for_status()
    time.sleep(2)                          # IBKR: wait 2 seconds before /iserver calls
    accounts = s.get(f"{BASE}/iserver/accounts", timeout=15).json()
    if not accounts.get("accounts"):
        raise RuntimeError("brokerage session not ready")
    return accounts["accounts"]

def keep_alive():
    r = s.post(f"{BASE}/tickle", json={}, timeout=15)
    body = r.json() if r.ok else {}
    return body.get("iserver", {}).get("authStatus", {}).get("authenticated", False)   # False: log in or re-init

if __name__ == "__main__":
    print("accounts:", start_brokerage_session())
    print("authenticated:", keep_alive())

Output against the stub:

accounts: ['DU0000000']
authenticated: True

The compete flag deserves attention: IBKR says (opens in a new tab) it decides whether other brokerage sessions are disconnected in favor of this one. If the same username is trading in TWS, this call can stop it, which is why a second username is the usual arrangement.

IBKR also lists an MCP server for AI tools (opens in a new tab) on api.ibkr.com, signed in through its own login screen. That is a separate product from the two APIs compared here and was not tested.

FIX, the third route

FIX is for order routing at volume, costs a monthly minimum and sends no market data, so it rarely fits a single trader's script.

IBKR's FIX page (opens in a new tab) asks for USD 10,000 minimum equity to apply and sets a monthly minimum commission of USD 1,500 for the first session and USD 1,000 for each further one, so two sessions mean USD 2,500 a month if commissions fall short. Its FAQ (opens in a new tab) says FIX carries orders only. Institutions need dedicated connectivity (opens in a new tab); others can run FIX over the internet through IB Gateway, where the pacing page (opens in a new tab) gives 250 messages per second. Onboarding (opens in a new tab) ends in a supervised certification test that includes unsolicited cancels, simulated trade busts and a line failure. FIX in general is covered in broker API integration.

Three cases: which IBKR API to build on

Match the route to who is being served: yourself, your reports or other people.

One trader's script on a VPS

The TWS API with IB Gateway is the lower-maintenance fit, because auto-restart limits manual logins to about one a week, against a daily browser login on the gateway. The server still needs a desktop session, since neither application runs headless, and someone must be available to complete 2FA when the login comes round. IB Gateway uses about 40% fewer resources than TWS, by IBKR's figure. The Web API suits you if your stack is not one of the supported languages and you accept the daily login.

A reporting tool for your own account

Start with the Flex Web Service (opens in a new tab): a token, a query you define in Client Portal, and no session to keep alive, so it cannot disturb live trading. It delivers reports rather than live data. For intraday positions, read-only Web API endpoints come next.

A product serving other people

On the Web API, an individual account cannot ship this: OAuth 2.0 is closed to individual structures, and third-party vendors (opens in a new tab) may currently seek approval only for OAuth 1.0a. IBKR expects an established business and a public site describing the product, and its three stage estimates add up to 8 to 14 weeks if they run in sequence. It also expects vendors of automated trading to hold registration in each region served, or a legal opinion on why none is needed. Software that each user connects to their own TWS or Gateway takes the TWS API route instead, and IBKR's integrations list (opens in a new tab) shows many such products. Its download page (opens in a new tab) still prohibits using the TWS API to pass market data to third parties without prior written approval.

Serving other people's accounts raises licensing questions that no API choice solves, so take legal advice first. Fincode does not offer account management. For general scoping, see project and product analysis or exchange API integration; naming IBKR here does not mean Fincode integrates it or has built on it.

Interactive Brokers API documentation: where it lives now

Current documents sit under interactivebrokers.com/docs, and the older locations either redirect, point onward or mark themselves deprecated.

Where these pages disagree, test on your own session rather than trusting either:

• Penalty box. The trading pacing page (opens in a new tab) says 10 minutes; the v1.0 page (opens in a new tab) says 15.
• /tickle. The pacing table lists GET; the endpoint page (opens in a new tab) shows POST.
• Idle timeout. The authentication FAQ gives both about 6 minutes and 5 minutes.
• Weekly login. The TWS download page and FAQ point to Sunday, after the Saturday reset; the reauthentication page says Monday.
• Ports. Quick-start code comments show 7946 and 7947; the Campus lesson and the sync documentation give 7496 and 7497.
• OAuth. The Web API introduction says authorization uses OAuth 2.0; the registration page excludes individual accounts.
• Third-party OAuth. The organizations page (opens in a new tab) lists OAuth 2.0 (beta) for third-party use; the third-party page allows only OAuth 1.0a.

All of these were read on the live pages on 5 November 2026; the main ones are listed under Sources.

Questions to answer before you commit

Five answers usually decide the route before any code is written.

1. Who logs in, and when? Name the person and the fallback for the weekly or daily login, including 2FA, and keep any credentials out of code, as API key security explains.
2. Will anyone use the same username elsewhere? A phone login can compete with the session, and IBKR says a Client Portal login with the username of a running TWS stops it reconnecting automatically after the next disconnection. Budget for a second username and its market data fee.
3. What happens during the restart? Decide what the program does with pending work while TWS, Gateway or /iserver is down.
4. Is anyone else's account or data involved? If yes, stop and read the third-party terms before choosing an API.
5. Which release do you pin? IBKR publishes Stable and Latest TWS API releases and retires old releases over time (opens in a new tab), so plan upgrades as ongoing work.

Frequently asked questions

Is the Client Portal API the same as the Web API?

Yes, in practice. IBKR's pages use Web API, Client Portal Web API and CPAPI for the same REST interface, and the Client Portal Gateway is the local program retail accounts use to reach it.

Can the IBKR Web API run without the gateway?

Only with OAuth, which calls https://api.ibkr.com directly. As read on 5 November 2026, that route is for approved institutions and vendors, and OAuth 2.0 is not available to individual account structures.

Is the TWS API faster than the Web API?

No latency comparison from IBKR was found, so no figure is given here. What it does publish is pacing: 50 requests per second by default on the TWS API and 10 per second on the Web API.

Can I use both APIs at the same time?

Not for trading on one username, because only one brokerage session can be active across all platforms. A second username works, with market data charged again, and read-only Web API calls can coexist with a TWS session.

Does the TWS API need TWS open?

It needs either TWS or IB Gateway running and logged in. IBKR treats them as equivalent for API purposes, and Gateway uses fewer resources.

Sources

• IBKR Web API: Introduction (opens in a new tab)
• IBKR Web API: Getting Started (retail and institutional) (opens in a new tab)
• IBKR Web API: Authentication introduction (opens in a new tab)
• IBKR Web API: Trading Sessions (start-up sequence, keep-alive) (opens in a new tab)
• IBKR Web API: Authentication FAQ (opens in a new tab)
• IBKR Web API: Limitations of the Client Portal Gateway (opens in a new tab)
• IBKR Web API: Pacing Limitations (opens in a new tab)
• IBKR Web API: Scheduled Server Maintenance (opens in a new tab)
• IBKR TWS API: Download TWS or IB Gateway (headless, restarts) (opens in a new tab)
• IBKR TWS API: Pacing Limitations (opens in a new tab)
• IBKR TWS API: Remote TWS API Connections (opens in a new tab)
• IBKR FIX: Requirements and Costs (opens in a new tab)
• IBKR Web API: Trading Access for Third Parties (opens in a new tab)
• IBKR TWS API: Changelog (opens in a new tab)
• SPK (Capital Markets Board): Notice on unauthorized leveraged transactions, 23 February 2023 (Turkish) (opens in a new tab)

This guide is general information about software and markets, not investment, legal or tax advice. Automated trading can lose money, past or backtested performance does not guarantee future results, and the rules that apply depend on your jurisdiction and your exchange's terms. Sources, checks and corrections: see the editorial policy.