How to Connect TradingView to Interactive Brokers for Automated Trading (2026)

TradingView does not natively place orders with Interactive Brokers. The “broker panel” inside TradingView only supports a curated list of partner brokers, and IBKR is not one of them. To get a TradingView alert to actually execute in your IBKR account, you need a webhook relay that receives the alert’s JSON payload, authenticates against IBKR’s API, and submits the order with the right contract ID, side, quantity, and time-in-force. The rest of this guide walks through exactly how that works, which relay architectures are viable, the failure modes that cause the most rejected orders, and when manual IBKR execution is still the smarter call.

Fast-Scan Summary

Why TradingView Alerts Don’t Reach IBKR on Their Own

A TradingView alert fires an HTTP POST to a URL you specify. That’s the entire delivery mechanism — there is no order type, no account routing, no authentication layer. TradingView ships the alert body you wrote (usually JSON) and walks away. Whatever receives the webhook is responsible for turning “BUY 100 SPY” into an actual order that clears risk checks and hits the exchange.

IBKR, on the other end, is the opposite: a heavyweight authenticated API with three distinct entry points — the legacy TWS API (TCP socket to TWS or IB Gateway), the Client Portal Web API (OAuth-based REST), and the FIX CTCI for institutional flow. None of them speak “TradingView alert.” Connecting the two requires a translation layer that: receives the webhook, looks up the correct IBKR contract ID (conID) for the ticker, builds a valid order dictionary, submits it against your authenticated session, and then reports status back so you know whether you actually got filled.

This translation layer is what every “TradingView-to-IBKR” guide is really describing, whether they call it a bridge, relay, connector, or webhook handler. The variations are about how you host and maintain it, not whether it exists.

The Three Viable Architectures

1. Self-Hosted TWS Gateway + Custom Script

You run IB Gateway (or full TWS) on a VPS, expose a small Flask or FastAPI webhook endpoint on the same box, and use a library like ib_insync or ib_async to translate incoming JSON into orders. Total cost: the VPS (~$8–15/month) plus your time. This is what most r/algotrading posts describe when someone asks “how do I do this for free.”

Where it gets you: full control, no recurring platform fees, unlimited custom logic. Where it breaks: IB Gateway requires a daily re-auth (Sunday maintenance window, plus weekly auto-restart), two-factor authentication makes unattended login a genuine engineering problem, and your script needs to handle disconnects, pacing violations (IBKR limits you to 50 messages/second), and session resurrection or your orders silently stop firing at 4 a.m. on a Thursday.

2. Client Portal Web API + Serverless Function

The Client Portal Web API is REST-based and doesn’t require a running TWS process. You deploy a Lambda, Cloudflare Worker, or similar serverless handler that receives the webhook, hits /iserver/account/orders, and returns. This is cleaner than the TWS route but imposes its own constraint: the Client Portal gateway still has to be kept alive via a “tickle” call at least every 60 seconds, which is awkward from a stateless serverless architecture. Some traders solve this with a cheap always-on container just for tickling — which defeats part of the serverless appeal.

3. Managed Webhook Relay

A managed relay (like Ontology Trading) runs the bridge for you: it maintains the IBKR session, handles re-authentication, normalizes your TradingView JSON into broker-specific order formats, and exposes a single webhook URL you paste into TradingView. You pay a subscription, you save the weekends of debugging why your Python script dropped its session at 2 a.m. The tradeoff is dependency on the vendor’s uptime and pricing.

End-to-End Setup: What Actually Happens on Alert Fire

Regardless of which architecture you choose, here is the concrete sequence between “alert fires” and “order filled”:

1. TradingView sends a POST to the webhook URL with your alert body (commonly JSON: ticker, action, quantity, optional price).
2. Relay authenticates against IBKR — either by validating an active TWS socket or by checking the Client Portal session is still live.
3. Symbol is resolved to a contract ID. “SPY” is not enough for IBKR; it needs the conID, the primary exchange, and the security type (STK/OPT/FUT). This is the single most common failure point for new users.
4. Order dictionary is built with side, quantity, order type (MKT/LMT/STP), time-in-force (DAY/GTC/IOC), and account code if you manage multiple accounts.
5. Order is submitted. IBKR returns either an order ID (accepted) or a rejection code with a reason.
6. Status is polled or streamed. Good relays subscribe to order events so a “filled” or “cancelled” webhook can fire back to you.

Total wall-clock time for the happy path: roughly 250–600 ms from TradingView’s server to IBKR’s acknowledgment, assuming your relay and IB Gateway are both co-located in a cloud region near TradingView’s webhook origin (typically us-east).

Comparison: Which Architecture Fits Which Trader

Prove-It: The Failure Modes No One Warns You About

Here are the specific rejections and errors most new users hit in their first two weeks, drawn from community post-mortems on r/algotrading, r/interactivebrokers, and Ontology support patterns:

1. Paper vs. live account mismatch. You tested on DU1234567 (paper) and forgot to flip the account code in your alert body. IBKR accepts the order against paper and you “see fills” that never moved real capital. Always include "account": "U1234567" explicitly in the payload and have the relay reject anything without it.
2. The conID trap. “AAPL” on SMART routes fine for stocks, but for options IBKR will reject the order unless you pass a specific expiry + strike + right combination. Many relays resolve this automatically; custom scripts often don’t.
3. Pacing violations on bracket orders. A bracket (entry + stop + target) is three API calls. If your alert fires on every bar close and you’re running 15 symbols, you can trip IBKR’s 50 msg/sec limit inside a minute. Symptoms: silent order failures, no error in TradingView, a cryptic “Max message rate exceeded” buried in TWS logs.
4. GTC behavior across weekends. IBKR’s Good-Till-Cancelled orders persist across sessions but are cancelled on corporate actions, dividends (for some option strategies), and account restrictions. If you automate re-entry on GTC, test what happens when the order is silently cancelled Friday and your strategy expects it live Monday.
5. Short sale locate failures. IBKR Lite accounts can’t short hard-to-borrow names; IBKR Pro can, but only when a locate is available. Your TradingView strategy may generate a short signal on a stock the relay cannot execute. Build an error path that tells you this happened — silent failures in short trades are the costliest bug in automated equity strategies.

Original Research: A 30-Day Webhook Latency Observation

Across 30 days of continuous monitoring (March 16 – April 15, 2026) on a managed relay handling TradingView alerts to IBKR Pro accounts, we tracked the end-to-end time from TradingView’s webhook send timestamp to IBKR’s order acknowledgment. Sample size: 4,118 alerts across 14 strategies.

Methodology note: latency measured from the TradingView webhook dispatch timestamp (present in the request header) to the IBKR orderStatus callback indicating “Submitted.” All relays and IB Gateways were in AWS us-east-1; TradingView’s webhook dispatch origin varies but is generally north American. Latencies will be materially higher if your IB Gateway runs on a home connection or a distant region.

The takeaway for strategy design: if your edge depends on sub-100ms execution, a TradingView-based architecture is the wrong choice — you want a direct FIX or native API strategy running co-located with the exchange. For swing, day, and position trading on equities, options, and futures, the latency distribution above is fine.

What a Working TradingView Alert Payload Looks Like

The exact JSON depends on your relay, but a canonical structure that most bridges accept is:

{
  "account": "U1234567",
  "ticker": "{{ticker}}",
  "action": "{{strategy.order.action}}",
  "quantity": {{strategy.order.contracts}},
  "order_type": "MKT",
  "tif": "DAY",
  "secType": "STK",
  "exchange": "SMART",
  "currency": "USD"
}

The double curly braces are TradingView placeholders that are substituted at alert-fire time with the strategy’s live values. A relay then uses ticker + secType + exchange to look up the IBKR contract ID before submitting. For a deeper breakdown of payload design, see our TradingView webhook guide library.

Not For You: When Automation to IBKR Is the Wrong Move

Some scenarios where you should not automate TradingView into Interactive Brokers, even if it’s technically possible:

• You’re trading size in illiquid names. A market order against a 500-share ADV stock will slip the spread wide. Automation with price-agnostic entries amplifies this. Manual execution with staged limits is better.
• You’re under PDT rules with a sub-$25K account. Automation will flip you into PDT violation territory fast if your strategy round-trips intraday. Trade cash-settled in a margin account, or use futures, or trade the strategy manually and keep trade count low.
• Your strategy fires many alerts per minute. IBKR’s pacing limits will throttle you. Rewrite the strategy to signal on bar close of a higher timeframe, or batch orders, before you automate.
• You haven’t run the strategy in paper for 30+ days. Every new strategy should run on DU paper accounts through the same webhook relay you’ll use live. If you can’t sit through 30 days of paper without touching the code, you will not sit through a drawdown in production.
• You only run your setup occasionally. The monthly cost of a managed relay will exceed the value delivered. Manual execution is the correct call.

FAQ

Can I use TradingView’s built-in broker panel with Interactive Brokers?

No. TradingView’s broker panel supports a partner list that includes Tradovate, Tradier, OANDA, Interactive Brokers’ own TWS via a desktop plugin in limited capacity for charting only, and a handful of others. It does not include automated order routing to IBKR via Pine Script alerts. You need a webhook relay.

Does IBKR charge an API usage fee?

No additional fee for the API itself. You pay the same commission schedule as manual trading. What you may pay for is market data subscriptions if your strategy needs real-time quotes beyond the default package — check IBKR’s market data rules before you assume your backtest data is available to your live strategy.

Do I need a TradingView Pro plan to use webhooks?

Yes. Webhook alerts are gated behind TradingView’s Pro, Pro+, or Premium tiers. The Essentials tier (free) does not include webhook alert delivery. If you plan to run more than a handful of simultaneous alerts, Premium is usually the right tier for its higher alert count.

How do I handle partial fills?

Your relay must listen to IBKR’s order status stream and handle the PartiallyFilled state as a first-class event. If you automate a stop-loss on entry fill, make sure it scales to the filled quantity, not the original order quantity. This is one of the most common sources of over-hedged or under-hedged positions in automated IBKR strategies.

Can I run multiple TradingView strategies against the same IBKR account?

Yes, but you need to decide how they share risk. Most traders either assign each strategy its own sub-account under a master IBKR account, or tag every alert with a strategy_id so the relay can enforce per-strategy position limits. Without this, two strategies can fight over the same symbol and produce round-tripping behavior that looks like a bug.

What happens during IBKR’s nightly server restart?

IB Gateway forces a re-authentication once per day (typically around 11:45 p.m. ET for US servers) and once per week on Saturdays for the full maintenance window. During this period, any alert that fires will fail unless your relay queues and replays on reconnect. Managed relays handle this; most DIY scripts do not, which is why Sunday evening positions sometimes show up Monday morning unexpectedly unfilled.

Next Steps

If you’re shipping your first TradingView-to-IBKR setup this week, the pragmatic path is: (1) build it in paper against DU account for at least 30 days before touching real capital; (2) pick an architecture that matches how much time you want to spend on infra vs. strategy; (3) log every webhook and every order response so the first rejection doesn’t turn into a mystery.

To skip the infrastructure build entirely and get a managed relay that handles the IBKR auth, contract resolution, and error retries out of the box, see how Ontology Trading routes TradingView alerts to Interactive Brokers and other supported brokers. If you’d rather build your own, the official IBKR Client Portal Web API docs are the starting point, alongside community library ib_insync for TWS API work.

Related Guides

• Ontology Trading — home
• AI Trading Strategy Builder
• TradingView webhook setup guide
• Connect TradingView to broker