Automate TradingView to Webull: The 2026 Architecture for Stocks, Options, and Crypto

Webull is one of the most-used commission-free brokers in the U.S., and its chart-trading UX has improved enormously since the 2024 platform rebuild. What it still does not have is a button inside TradingView that says “Connect Webull” the way Interactive Brokers, Alpaca, and tastytrade do. That gap is exactly why this article exists. If you want a TradingView alert (or a Pine Script strategy.entry firing off a backtest signal) to actually submit a live order into your Webull account without you clicking anything, you need a relay in the middle, and you need to understand what Webull’s API expects on the wire.

This guide is for traders who are about to push real capital through this pipeline. It covers why a direct TradingView-to-Webull link does not exist, what the relay has to do, the OAuth and order-format details Webull’s Open API demands, the latency and cost math, and the failure modes that bite people in production. There is also an honest “Not For You” section at the end – Webull automation is the right answer for many setups and the wrong answer for others.

Why TradingView Has No Native Webull Button

TradingView’s “Trading Panel” supports a fixed list of connected brokers – Interactive Brokers, OANDA, Alpaca, tastytrade, TradeStation, Tradier, FXCM, and a handful of others. Webull is not on that list and has not been added in several review cycles, partly because Webull’s retail Open API only opened to developer partners through their Corporate Connect program, not as a self-serve consumer API the way Alpaca’s is. The result: TradingView users who trade Webull have two real choices – place orders manually after the alert, or run a webhook through a relay that holds a Webull API token.

The relay matters because TradingView’s alert system can only POST a JSON body to a public HTTPS URL. It cannot attach a custom Authorization header, cannot store a bearer token, cannot refresh that token before it expires, and cannot retry a failed call against a different endpoint. Webull’s API requires an Authorization: Bearer {token} header on every request and uses short-lived access tokens with longer-lived refresh tokens. A naked TradingView webhook can never satisfy that contract. A relay can. This is the same architectural reality behind every TradingView-to-broker pipeline, but Webull’s case is sharper because there is no consumer-facing API portal to sign up for – access goes through approved partners.

The Three Pieces of a Working Pipeline

Every functional TradingView-to-Webull automation has the same three components, regardless of whether the trader builds it from scratch or pays a managed platform to host it:

1. A TradingView alert firing from an indicator’s alert() call or a strategy’s strategy.entry / strategy.exit calls. The alert POSTs a JSON body to a public HTTPS endpoint.
2. A webhook relay that validates the request is genuine (shared secret, IP allowlist, or HMAC), transforms the payload into Webull’s order format, attaches the OAuth bearer token, and submits the order. It also logs the result and surfaces failures.
3. Webull’s Open API, which receives the order through a partner-issued endpoint and either accepts, rejects, or queues it for routing.

The relay is where all the engineering lives. It has to respond to TradingView in under three seconds (TradingView’s default webhook timeout, after which the alert is marked failed), survive Webull’s per-account rate limit (observed in production at roughly five requests per second sustained, with bursts up to ten), refresh OAuth tokens before they expire, and not silently lose orders during partial outages. Most traders end up either renting a small VPS in AWS us-west-2 (close to TradingView’s webhook origin in Oregon) and writing the relay themselves, or using a managed platform like Ontology Trading that already has the Webull route, the OAuth refresh, and the rate-limit-aware queuing built in.

The Four Routing Paths and Their Tradeoffs

The fourth path is genuinely interesting for high-frequency automation but throws away the reason most people use TradingView in the first place: the chart, the indicator library, and the alert UI. The first three paths preserve TradingView as the brain and use Webull only as the execution venue.

What Webull’s Open API Actually Expects

Webull’s Open API is REST-based, returns JSON, and authenticates with OAuth 2.0 bearer tokens. Order submissions go to a partner-specific orders endpoint (the exact host varies by partner agreement). A single market buy of 10 shares of AAPL looks roughly like this in the request body:

{
  "account_id": "WBA-XXXXXXXX",
  "symbol": "AAPL",
  "instrument_type": "EQUITY",
  "side": "BUY",
  "order_type": "MARKET",
  "time_in_force": "DAY",
  "quantity": 10,
  "client_order_id": "tv-2026-04-25-001"
}

An options order adds the OCC-format option symbol, the contract count, and an open/close action:

{
  "account_id": "WBA-XXXXXXXX",
  "symbol": "AAPL  260515C00200000",
  "instrument_type": "OPTION",
  "side": "BUY_TO_OPEN",
  "order_type": "LIMIT",
  "time_in_force": "DAY",
  "quantity": 1,
  "limit_price": 3.45,
  "client_order_id": "tv-2026-04-25-002"
}

Constructing that OCC option symbol (AAPL 260515C00200000 for the AAPL May 15, 2026 $200 call) is one of the more error-prone parts of building this yourself. The relay has to encode the underlying, expiration date, right (C/P), and strike price (in thousandths of a dollar, padded to eight digits) correctly. A managed platform abstracts that into a simple payload like {"underlying":"AAPL","expiry":"2026-05-15","strike":200,"right":"C","action":"buy_to_open"} and constructs the OCC string for you. Off-by-one errors in expiration encoding are the leading cause of malformed-symbol rejections.

Mapping a Pine Strategy Alert to a Webull Order

Inside a Pine Script strategy, the alert message uses placeholder tokens that TradingView replaces at fire time. A relay-ready alert body for a single-leg equity entry looks like:

{
  "ticker": "{{ticker}}",
  "action": "{{strategy.order.action}}",
  "contracts": "{{strategy.order.contracts}}",
  "position_size": "{{strategy.position_size}}",
  "price": "{{close}}",
  "timestamp": "{{timenow}}",
  "secret": "your_shared_secret_here",
  "broker": "webull"
}

The relay receives this, validates the secret field against an env-stored value, looks up the action (“buy” → “BUY”, “sell” → “SELL” if flat, or “SELL” with appropriate position-close logic if long), constructs the Webull payload, attaches the bearer token, and POSTs it. For options strategies, the alert body adds expiration and strike fields encoded as literals in the alert message text – Pine doesn’t have native placeholders for those.

One Webull-specific wrinkle: position sizing logic (“buy 2% of available equity”) almost always has to live in the relay because Pine has no way to query your real Webull account balance. The relay does an account-info read against Webull’s API at fire time, computes the share count, and submits the sized order. This adds 50-150 ms but is unavoidable for any equity-percentage strategy.

Latency Budget: What “Fast Enough” Looks Like

The end-to-end pipeline from “Pine condition becomes true” to “Webull order acknowledged” has four stages:

Total realistic budget: 180 ms to 1.1 seconds for a clean run with no resizing, or 230 ms to 1.25 seconds with an account-info-driven size calculation. Production data from automation platforms clusters around 250 – 800 ms end-to-end during regular trading hours. Around the cash open at 9:30 ET and during major news events, the pipeline can balloon past five seconds because both TradingView’s webhook queue and Webull’s order-routing queue back up. A relay running in US-East-1 can add 100 – 200 ms versus one co-located in US-West-2.

The Cost Math: Where Webull Saves and Where It Doesn’t

Webull’s commission structure is one of the reasons traders pick it. Stocks and ETFs trade at zero commission. Options carry a per-contract regulatory and clearing fee but no Webull commission. Crypto trades through Webull Pay carry a spread markup rather than an explicit commission. The breakdown matters when you’re sizing automated strategies that round-trip many times per day:

For an automated equity scalper running on 100-share lots, the round-trip cost is well under a dollar – small enough that strategy edge calculations can effectively ignore commissions and focus on slippage and the bid-ask spread. For a 0-DTE options scalper, the per-contract fees add up: a strategy that round-trips 50 contracts a day pays roughly $5 – $10 in regulatory and clearing fees daily, which has to be netted out of the gross edge. Crypto on Webull Pay is the expensive case – the implied 100-bps round-trip spread is the same order of magnitude as a typical short-term mean-reversion edge, so most automated crypto traders use Coinbase or Kraken instead and route through the same TradingView relay infrastructure.

PDT, Margin, and Other Account-Type Gotchas

The most common reason an automated Webull strategy works in backtest and dies in live trading is the Pattern Day Trader rule. If your account equity is under $25,000 and you make four or more day trades in a five-business-day window, your account gets flagged and you can be restricted for 90 days. Pine strategies that scalp intraday will trip this constantly on a small account.

The relay should know the account type and the running day-trade count and refuse to submit a fourth day trade in a rolling five-day window if equity is under $25k. A managed platform exposes this as a simple “PDT-aware mode” toggle. A DIY relay has to query the account’s day-trade count from Webull’s API on every entry attempt and gate the submission accordingly. Without that gate, the alert fires, Webull accepts the order, and the next morning the account is restricted – the strategy keeps generating signals but the broker rejects every one of them, and the trader doesn’t notice until they check the app.

Other Webull-specific account behaviors worth gating in the relay: extended-hours trading flag (Webull’s pre-market opens at 4:00 AM ET; if you don’t want strategy fills at 5:00 AM, the relay must filter), options approval level (level 2 vs 3 vs 4 controls which strategies can submit), short-sale availability (Webull’s locate list refreshes overnight; some symbols are HTB and the order will reject), and Reg T margin call status (an account in a margin call cannot open new positions).

Original Data: A 30-Day Webhook-to-Webull Failure Mode Audit

We pulled 30 days of webhook submissions across automated Webull accounts running through our infrastructure. Failure modes broke down as follows:

The two findings worth highlighting: half of all failed automated Webull orders come from token rotation problems and PDT violations, neither of which is a market-condition or strategy-quality issue. They are infrastructure problems. A relay that handles token refresh cleanly and gates day-trade count against account equity eliminates roughly half of all observed failures, which is the difference between “this works in production” and “this kind of works most days.”

What Real Automation Looks Like for Three Common Webull Setups

1. Daily breakout scanner on a watchlist of 30 small caps. Pine fires when a price breaks above the prior day’s high on volume. The alert posts to the relay, the relay sizes position based on 1% of equity, checks PDT status, checks buying power, and submits a Webull market or marketable-limit order. Gotcha: small caps often have wide morning spreads, so a market order at 9:31 AM can fill 50 – 100 cents off the prior trade. Relay should default to a marketable limit at the asking price plus a small slippage budget, not a pure market.

2. End-of-day swing entry on a daily TradingView signal. Pine fires at the 4:00 PM ET daily close, the alert posts to the relay, the relay sizes the position, and Webull queues the order for the next session’s 9:30 AM open. Gotcha: Webull supports MOC (market-on-close) and MOO (market-on-open) order types via API, but each has cutoff times before which the order must be received. Submitting at 4:00:01 PM ET is too late for that day’s MOC. The relay needs to know the cutoff and either route to extended hours or queue for next-day open.

3. Options vertical on a daily SPY signal. Pine fires once per day, the alert encodes the strike, expiration, and right in the message body, the relay constructs the multi-leg order, and Webull routes it. Gotcha: Webull’s API requires options approval level 3 or higher for spread orders. If your account is approved for level 2 (long calls/puts only), the spread submission rejects with no clear error. Relay should pre-check options approval level on account setup, not at fire time.

Not For You: When TradingView-to-Webull Automation Is the Wrong Choice

If your strategy is genuinely tick-by-tick (sub-100ms reactions to market microstructure), Webull’s API is not the right venue. You want a colocated direct-market-access broker with FIX connectivity. Webull’s Open API was designed for retail-scale order flow and is not a low-latency execution venue.

If you trade primarily futures, Webull does not offer futures trading. You’ll need a different broker for that side – tastytrade, Tradovate, or Interactive Brokers all support futures and integrate with the same TradingView relay infrastructure.

If you trade only crypto and care about cost, Webull Pay’s spread markup is materially worse than Coinbase Advanced or Kraken Pro for any size. Use one of those venues and route through the same TradingView relay setup. Ontology Trading supports crypto routes to Kraken and Coinbase out of the same alert pipeline as the Webull route.

And if your “automation” is one or two trades per week on a weekly chart signal, the maintenance overhead of a relay (OAuth, monitoring, alert routing, PDT gating) probably is not worth it. Place those by hand from the alert email and use the time you save to refine the strategy.

FAQ

Does Webull have a direct TradingView integration like Alpaca or Interactive Brokers?

No. Webull is not in TradingView’s native broker list and has not been added in several review cycles. Automation requires a third-party relay sitting between the TradingView webhook and Webull’s Open API to hold the OAuth bearer token, transform the payload, and submit the order. Manual chart-based trading from inside Webull’s own apps works, but it is not the same as TradingView-driven automation.

What kind of API access does Webull offer for automated trading?

Webull’s Open API is offered through their Corporate Connect partner program rather than as a self-serve consumer portal. Most retail traders access it through a managed automation platform that holds the partner relationship, provisions accounts, and handles the OAuth flow. Direct partner application is possible but the review and onboarding process is longer than signing up for an Alpaca or tastytrade developer account.

Can I automate options spreads through TradingView alerts to Webull?

Yes, with a relay that supports multi-leg payloads and an account approved for options level 3 or higher. The relay constructs the multi-leg JSON payload using OCC-format option symbols and submits it to Webull as a single combo order. Single-leg long calls and puts work at level 2; verticals, iron condors, and other defined-risk spreads require level 3.

Will the Pattern Day Trader rule shut down my automated Webull strategy?

It will if your account equity is under $25,000 and your strategy makes four or more day trades in any rolling five-business-day window. The relay must gate against this by querying Webull for the live day-trade count and refusing to submit the fourth qualifying trade. Without that gate, the broker accepts the trade and then restricts the account, after which all further automated entries reject silently.

What’s the typical latency from TradingView alert to Webull order acknowledgment?

Production pipelines cluster between 250 and 800 ms end-to-end during regular market hours. The biggest variances come from relay region (US-West-2 saves 100-200 ms versus US-East), whether the relay does a live account-info read for position sizing (adds 50-150 ms), and market conditions (the 9:30 ET open and major news events can stretch the pipeline past five seconds because both TradingView and Webull queue depths balloon).

Is the TradingView Essential plan enough to automate Webull, or do I need Premium?

Essential supports webhook alerts, which is the only TradingView feature the integration actually requires. Premium tiers add more concurrent alerts, second-resolution data, and faster server-side alert evaluation. If you run a single strategy on a daily or hourly chart, Essential is fine. If you run many strategies across many symbols on minute charts, Premium’s higher alert ceiling and faster evaluation start to matter.

Putting It Together

TradingView-to-Webull automation is structurally identical to every other broker pipeline – alert, relay, broker API – but Webull’s lack of a direct TradingView integration and its partner-only API access make it more demanding than brokers with self-serve developer portals. The trader who succeeds at this either invests engineering time into a hardened relay with OAuth refresh, PDT gating, position sizing logic, and rate-limit-aware queuing, or pays a managed platform to own that surface area.

If you want to skip the DevOps and put alerts directly into your Webull account with sub-second latency, OAuth handled, PDT gating built in, and failure alerting ready out of the box, Ontology Trading is built for exactly this stack. The same alert configuration also routes to Interactive Brokers, Alpaca, tastytrade, Coinbase, Kraken, and others if you trade across multiple brokers from the same TradingView account. For traders who want to build it themselves, the architecture above is the blueprint – and the OAuth, PDT, and partner-API onboarding are where most DIY projects either succeed or quietly fail.

Related Reading

• Ontology Trading – Automate TradingView to Any Broker
• AI Trading Strategy Builder – Build Complex Strategies Without Code
• Contact Ontology – Setup Help and Custom Integrations