Read time … min

AI-native runtime for Interactive Brokers strategies

Author in Cursor, Claude Code or any AI IDE. Deploy from GitHub into a managed cloud runtime with first-class MCP control, logs and region selection.

By the TradingHost engineering team

Section 01 · At a glance

At a glance

Broker
Interactive Brokers LLC (Interactive Brokers Group, NASDAQ: IBKR)
Broker type
US-regulated multi-product broker, retail and institutional
Asset class
US and international equities, options, futures, FX, bonds, ETFs, mutual funds, crypto, CFDs (non-US)
Asset coverage
US equities (NYSE, NASDAQ, NYSE ARCA, BATS, IEX) and international equities on 150+ markets across 33 countries. US options (OCC-cleared equity and index) and options on futures. Futures and FOPs on CME Group, ICE, Eurex, HKEX, OSE, SGX and others. FX spot (100+ pairs, IDEAL FX network). Bonds: US Treasuries, US municipals, US corporate, international government and corporate. ETFs and mutual funds. Crypto trading (US clients) on a partnered platform; non-US clients via separate IBKR entities. CFDs and warrants on non-US entities. Structured products.
Runtime model
Containerised strategy runtime
Deployment source
GitHub
Languages
Any language that runs in a container
Common integrations
TWS API (ibapi official Python, ib_insync, ib_async), Client Portal API (REST + OAuth2), Web API, FIX (institutional), NautilusTrader, Backtrader, custom connectors
AI workflow integration
MCP control surface for Cursor, Claude Code, GitHub Copilot and CLI agents
TradingHost role
Runtime, deployment, logs, health checks, region selection, MCP control
Interactive Brokers role
Broker account, API access, market data, execution venue, custody, settlement, tax reporting, margin management
Regulators
Interactive Brokers LLC: SEC and FINRA registered broker-dealer (CRD 36418), CFTC/NFA registered Futures Commission Merchant and Forex Dealer Member (NFA ID 0258600). SIPC member with excess insurance via Lloyds. Group entities are additionally regulated by FCA (UK), CIRO (Canada), ASIC (Australia), SFC (Hong Kong), MAS (Singapore), CBI (Ireland), and others.
US retail
Yes. Paper trading account included.
Affiliation
TradingHost is independent and is not affiliated with Interactive Brokers LLC or Interactive Brokers Group, Inc.

Section 02 · What IBKR offers

What Interactive Brokers offers

Interactive Brokers exposes three distinct API surfaces (TWS API, Client Portal API, Web API) plus institutional FIX. The same account credential reaches US and international equities, options, futures, FX, bonds, ETFs, mutual funds, crypto, and CFDs on non-US entities. The three API surfaces have materially different capability envelopes; the choice is part of the strategy design.

Markets and strategy patterns

  • Multi-asset portfolios across equities, options and futures
  • International equity strategies on 150+ markets via Smart Routing
  • CME, ICE and Eurex futures and options-on-futures automation
  • IDEAL FX spot strategies on 100+ pairs
  • Vol-surface and Greeks-aware US options strategies
  • Portfolio margin and cross-asset margining workflows
  • Paper trading account for parallel risk-off testing

API surface

Product surfaces
Three distinct API surfaces from Interactive Brokers: TWS API (socket protocol, requires a locally running Trader Workstation or IB Gateway process), Client Portal API (REST + WebSocket, OAuth 2.0 authenticated), and Web API (newer REST surface). FIX is offered for institutional clients. Each surface has materially different capabilities; choose per strategy.
Connection methods
TWS API uses TCP sockets to a running TWS or IB Gateway instance on ports 7496/7497 (live/paper) for TWS or 4001/4002 (live/paper) for IB Gateway. Client Portal API is HTTPS REST plus WebSocket on api.ibkr.com. Web API is HTTPS REST. Wrappers: official ibapi (Python), community ib_insync, and the ib_async fork that continues maintenance.
Authentication
TWS API: the strategy connects to a locally running gateway that was authenticated interactively by the account holder. Client Portal API: OAuth 2.0 with consumer key and refresh tokens. Web API: REST tokens. Paper trading uses separate credentials and a separate account number from live.

For specifics, refer to Interactive Brokers

Specific endpoints, rate limits, account minimums, options approval tiers, market data subscriptions and per-market commission schedules live in Interactive Brokers' documentation. Treat these as the source of truth.

Section 03 · Build with AI

Build your IBKR strategy with AI

Pick an integration method (TWS API for broadest capability, Client Portal API for cloud-only without a local gateway), fork a starter, and author your strategy in an AI IDE. Cursor, Claude Code, GitHub Copilot and CLI-based AI agents all work with the same GitHub-native deployment loop.

  • TWS API (socket)

    The flagship IBKR API. Highest capability surface but requires a locally running TWS or IB Gateway process the strategy connects to. Use ibapi (official) or ib_async (community asyncio fork of ib_insync) for Python.

    tws-api on GitHubib_async on GitHub

  • Client Portal API (REST)

    REST plus WebSocket surface authenticated via OAuth 2.0. Lighter capability than TWS API but does not require a local gateway, which is friendlier for cloud-only deployments.

  • Web API (REST)

    Newer REST surface from IBKR. Subset of capability versus TWS API and Client Portal at present; coverage is being expanded.

  • Framework or custom connector

    NautilusTrader, Backtrader, QuantConnect and in-house engines all wrap the TWS API surface. Choose per the framework you already use.

Library and framework support for IBKR products

ibapi and ib_async cover the full TWS API surface, which is IBKR's broadest capability set. Client Portal API trades off some advanced order types for cloud-friendly REST + OAuth2. Framework adapters (NautilusTrader, Backtrader) all wrap one of the underlying surfaces; capability inherits from the surface they wrap.

Library or frameworkUS equitiesIntl equitiesOptionsFuturesFX
ibapi (official Python)SupportedSupportedSupportedSupportedSupported
ib_async (community fork)SupportedSupportedSupportedSupportedSupported
Client Portal APISupportedPartially supportedSupportedSupportedSupported
NautilusTrader (IBKR adapter)SupportedPartially supportedPartially supportedSupportedSupported
Backtrader (IB store)SupportedPartially supportedPartially supportedSupportedPartially supported

✓ confirmed support per the library or adapter’s docs. "partial" indicates partial coverage; verify against the integration’s current docs before relying on it.

TradingHost does not force a library. It runs your project.

Author with AI

ibapi, ib_async and Client Portal API REST clients all work with AI IDEs. The TradingHost MCP control surface closes the loop: AI tools can inspect deployments, review logs and manage the runtime alongside you, never the trade execution path.

Section 04 · Run on TradingHost

Run your code on TradingHost

Interactive Brokers provides the broker account, API access and execution venue. TradingHost provides the production environment where your IBKR-connected strategy runs.

Instead of running strategy code on a laptop, desktop machine, generic VPS or manually configured server, you deploy from GitHub into a TradingHost-managed container runtime.

You

  • Your repo contains your code.
  • Your deployment defines how it runs.
  • Your strategy connects to Interactive Brokers.

TradingHost

  • Keeps the runtime online.
  • Surfaces logs and health checks.
  • Region selection.
  • Controlled deployment surface.

Deployment flow

  1. STEP 01

    Connect GitHub

    Authorise TradingHost to access your GitHub account.

  2. STEP 02

    Link a repo or start from a starter

    Point TradingHost at your existing IBKR strategy repo, or fork an ibapi or ib_async starter for a working baseline.

  3. STEP 03

    Deploy into a TradingHost container

    Pick a region (US-East sits closest to US equities and CME futures matching engines; EU is the natural pick for European session strategies and Eurex futures), supply your IBKR credentials and gateway configuration as environment values, and deploy. TradingHost builds your container from the repo and runs your strategy on managed Kubernetes infrastructure. TWS API strategies that require a local IB Gateway process can run that gateway as a sidecar; Client Portal API and Web API strategies do not need a gateway.

  4. STEP 04

    Monitor logs and health

    Watch live logs, health and runtime state from the TradingHost dashboard. The same surface is reachable through MCP from any AI IDE, so Cursor, Claude Code or a CLI agent can read deployment state and manage the runtime alongside you. Trade execution stays on the strategy code path, not on MCP.

  5. STEP 05

    Update and redeploy

    Push changes to your GitHub main branch and TradingHost redeploys automatically. A paper-account-keyed deployment is the natural test environment before promoting to live keys.

Deploy

Section 05 · Operational notes

Operational notes for Interactive Brokers

Things that bite you when you actually run an Interactive Brokers strategy in a containerised cloud runtime, not always in IBKR’s docs, not in framework READMEs. Every claim below is quoted or paraphrased from Interactive Brokers’ own documentation or a primary regulator source; the deployment-side guidance is from running these strategies on TradingHost.

  1. 01 · Three API surfaces

    TWS API, Client Portal API and Web API are not interchangeable

    Interactive Brokers exposes three distinct programmatic surfaces. TWS API is a socket protocol used by ibapi and ib_async; it requires a running TWS or IB Gateway process the strategy connects to. Client Portal API is REST plus WebSocket with OAuth 2.0; it does not need a local gateway. Web API is a newer REST surface with narrower coverage today. Choose the surface during strategy design; switching mid-deployment is a rewrite, not a flag flip.

    SourceInteractive Brokers API portaltws-api on GitHub

  2. 02 · TWS local gateway

    TWS API requires a local TWS or IB Gateway process the strategy connects to

    TWS API is a socket protocol that connects to a locally running TWS (Trader Workstation) or IB Gateway instance on port 7496 or 7497 for TWS, or 4001 or 4002 for IB Gateway (live and paper respectively). For cloud-only deployments, either run IB Gateway as a sidecar container alongside the strategy, or use Client Portal API instead. The "local" gateway can live in the same TradingHost container or in an adjacent one in the same Kubernetes pod.

    SourceIB Gateway documentation

  3. 03 · Paper account

    Paper trading is a separate account number with separate credentials

    Paper trading on Interactive Brokers is delivered as a separate account number rather than a separate environment URL. The user logs into TWS or IB Gateway with paper credentials and the gateway connects to the paper service. Strategy code does not change between paper and live, but the gateway configuration and the API connection (port and account ID) does. Keep paper and live credentials in separate TradingHost Secrets entries.

    SourcePaper trading account, IBKR docs

  4. 04 · Pattern Day Trader

    PDT applies to margin accounts under $25,000 per FINRA Rule 4210

    FINRA Rule 4210 marks a margin account as Pattern Day Trader after four or more day trades within five business days, and restricts further day trading until equity reaches $25,000. Interactive Brokers enforces this rule on margin accounts. Cash accounts are not subject to PDT but are subject to settlement-cycle constraints (T+1 for US equities since 2024-05-28). Plan deployment around the constraint.

    SourceIBKR PDT documentationFINRA Rule 4210

  5. 05 · Options approval

    Options approval is per account and separate from equities approval

    Options trading on IBKR requires a separate approval step beyond brokerage onboarding. Approved level controls which option strategies the broker accepts: covered calls and cash-secured puts at the lowest tier, uncovered short options at the highest. Orders that exceed the approved level are rejected at the broker, not at TradingHost. Plan strategies around your approved level or upgrade approval with IBKR before deploying.

    SourceIBKR options trading permissions

  6. 06 · Market data

    Market data subscriptions are per-market and not bundled by default

    Interactive Brokers charges market data subscriptions per market (US NASDAQ depth, NYSE OpenBook, OPRA US options, CME futures, LSE depth, and so on). A strategy that queries unsubscribed market data receives delayed quotes or empty responses. Set data subscriptions on the user portal before deploying a strategy that depends on real-time data on a specific market.

    SourceIBKR market data subscriptions

  7. 07 · SmartRouting

    SmartRouting is the default; direct routing is per-order

    Interactive Brokers routes orders through SmartRouting by default, which selects the venue with the best displayed price net of commissions. To direct route, specify an exchange parameter on the order. SmartRouting affects fills, latency, and exchange-fee rebates; strategies that depend on specific venue interaction must opt into direct routing.

    SourceIBKR SmartRouting overview

Section 06 · Built for

Built for

TradingHost Interactive Brokers runtimes are best suited to:

  • Developers building strategies in AI IDEs (Cursor, Claude Code)
  • Multi-asset systematic traders
  • Options and futures strategy operators
  • Quant developers moving from notebook to production
  • International equity and FX strategy authors

Connecting GitHub and creating your first strategy is free.

Section 08 · FAQ

FAQ

No. TradingHost is independent and is not affiliated with Interactive Brokers LLC or Interactive Brokers Group, Inc.

No. TradingHost is a runtime for trading strategy code. Interactive Brokers LLC is the broker-dealer, registered with the SEC and FINRA (CRD 36418), CFTC and NFA (NFA ID 0258600), and a SIPC member with excess insurance via Lloyds. Your account, custody, market access, settlement, margin and tax reporting all sit with Interactive Brokers.

No. Your strategy code connects to Interactive Brokers and sends order instructions according to your own logic, account permissions and integration method. TradingHost provides the runtime where that code runs.

No. IBKR API access is provided by Interactive Brokers. You are responsible for your IBKR account, API permissions, credentials and compliance with IBKR's terms.

TWS API (via ibapi or ib_async) has the broadest capability surface but requires a locally running TWS or IB Gateway process. Client Portal API is REST plus OAuth 2.0 and does not need a local gateway, so it is simpler for cloud-only deployments. If your strategy needs advanced order types, real-time options Greeks, or features that only the TWS socket protocol exposes, use TWS API and run IB Gateway as a sidecar. If REST works, prefer Client Portal API for the easier deployment shape.

Yes if you choose TWS API. IB Gateway is a small Java application that authenticates against IBKR and exposes a local socket the strategy connects to. On TradingHost you run IB Gateway as a sidecar process in the same Kubernetes pod as the strategy, or use Client Portal API instead, which removes the gateway dependency.

Yes, subject to IBKR options approval. Options approval is per account and separate from equities approval; the level controls which strategies the broker accepts. TradingHost does not bypass options approval.

Yes, subject to IBKR futures account approval. Futures trading requires a separate approval step beyond brokerage onboarding because of CFTC and NFA requirements.

ibapi is the official Python wrapper from Interactive Brokers and reflects the socket protocol directly. ib_insync was a community asyncio-friendly wrapper; its original author marked it as not actively maintained. ib_async is the community fork of ib_insync that continues to ship updates. For new strategies, use ibapi or ib_async; for existing ib_insync code, plan a migration to ib_async because the API is largely compatible.

Connect your GitHub repo containing the strategy code, link it to TradingHost, and deploy. Use a paper-account-keyed deployment as the test environment, and promote to live keys once the strategy is stable. Linking GitHub and creating a strategy is free; runtime plans are listed on the pricing page.

In your GitHub-controlled secrets workflow. TradingHost reads them at runtime through GitHub repository secrets, environment secrets or your own approved secret-management process. TradingHost does not need custody of your IBKR username, password, or Client Portal OAuth tokens. See platform secrets for the full handling model.

No. Strategies should never need withdrawal or money-movement permissions. The credentials only need the scopes required for order placement and market data access.

Yes. TradingHost supports MCP-based control for AI IDEs including Cursor, Claude Code, GitHub Copilot and CLI-based AI agents. AI tools can inspect deployments, review logs, restart strategies and manage runtime workflows. MCP is a control and observability surface, not the trade execution path. See the MCP control surface for the full picture.

No. The PDT rule (FINRA Rule 4210) is enforced by Interactive Brokers, not by TradingHost. Margin accounts under $25,000 are subject to PDT restrictions on day trading. Your strategy should respect the broker's PDT flag on the account.

No. Your 1099 forms come from Interactive Brokers at year-end, not from TradingHost. TradingHost provides the runtime; IBKR handles brokerage tax reporting.

No. SIPC covers your IBKR brokerage account up to $500,000 (including $250,000 in cash) under SIPC member protection, with additional excess insurance offered by IBKR via Lloyds. TradingHost's runtime is not SIPC-insured because TradingHost is not a broker.

TradingHost runs in the EU and US-East regions. US-East is closest to US equities and CME futures matching engines, which is the natural pick for most IBKR US strategies. The EU region makes sense for European session strategies and Eurex futures. See the regions page for routing and proximity details.

No. TradingHost is focused on production runtime and deployment. Backtesting belongs in your research stack, framework or AlgoBuilder.