TradingView Webhook vs REST API vs MCP: How to Automate Tradovate and NinjaTrader 8

You have a TradingView strategy that produces alerts. The next decision is which interface carries the instruction into your Tradovate or NinjaTrader 8 account: a webhook, a REST API request, a WebSocket message, or an MCP tool call.

Those terms are often treated as interchangeable. They are not. The practical rule is to choose by who owns the next action: TradingView, your application, or an AI assistant.

This guide compares the current CrossTrade surfaces for both platforms so you can choose the simplest fit and test the complete workflow in simulation before anything touches live risk.

The short answer

The same trading intent can be submitted through more than one interface. The difference is who makes the call, how it authenticates, what state it can read, and how you verify the result.

Webhooks: the alert fires, the order goes

A webhook is a URL that accepts a message. In TradingView, you create an alert with a webhook notification, paste in your permanent CrossTrade webhook URL, and send the command as plain text. There is no SDK, code compilation, or server of your own.

CrossTrade's webhook API documentation shows the payload shape:

key=your-secret-key;
command=place;
account=Sim105;
instrument=MES 09-26;
action=buy;
qty=1;
order_type=market;
tif=day;

Authentication uses the permanent webhook URL plus the CrossTrade secret in the message body. It does not use a REST Bearer token. Keep both out of public scripts, screenshots, and shared prompts.

Routing is explicit. When destination is omitted, the alert routes to NinjaTrader 8. Add destination=tradovate; for a linked Tradovate account. The current destination compatibility matrix is the source of truth for shared commands and broker-specific fields.

This is the best interface when TradingView owns the signal and you want a human-readable delivery trail. CrossTrade Alert History records webhook attempts and their resolved destination. For Tradovate, a green row means the broker accepted the request, not that the order filled or finally rested. Verify broker state before retrying an unclear result.

CrossTrade's current public API page displays a <50ms average-response marketing metric. That is vendor-published data, not a promise for an individual TradingView-to-broker order and not a Tradovate latency guarantee. Network conditions, account state, payload logic, and broker response all affect an end-to-end result. Measure the exact path on your own simulation setup.

The limit is equally clear: a webhook is one-shot. It does not stream state or answer follow-up questions. Conditional behavior must live in TradingView logic or in supported CrossTrade commands and options, such as brackets, ATM configuration, close, reverse, and risk controls.

REST API: your code makes the calls

Use REST when your own application or script decides what to do. The application sends a request, receives a response, records the result, and reconciles any uncertain mutation before retrying.

CrossTrade exposes two REST route families:

• NinjaTrader 8: /v1/api, executed through the CrossTrade Add-On in a running NT8 instance.
• Tradovate: /v1/api/tv, executed server-side against a linked Tradovate identity with no NT8 Add-On required.

The CrossTrade API overview documents the platform split. The Tradovate REST reference covers linked accounts, positions, orders, fills, balances, contract lookup, and trading operations. Both use a CrossTrade Bearer token, but their route prefixes and runtimes are not interchangeable.

REST fits scheduled jobs, custom dashboards, journaling integrations, and logic that is too complex for an alert body. A NinjaTrader order uses POST /v1/api/accounts/{account}/orders/place. A Tradovate order uses POST /v1/api/tv/accounts/{account}/orders/place. The body fields differ in places, so use the platform tab in the endpoint documentation rather than assuming one payload works unchanged on both.

Unlike a webhook, a direct REST call does not create a webhook Alert History row. Your application owns logging, retries, and reconciliation. Save the account, instrument, request ID or order ID, response, and timestamp. If placement has an ambiguous result, read current order state before deciding whether another write is safe.

WebSocket: persistent NT8 RPC and streams

A WebSocket keeps a connection open between your application and CrossTrade. The current endpoint is wss://app.crosstrade.io/ws/stream, authenticated with the same Bearer token used for the REST API.

For NinjaTrader 8, the socket can send supported RPC calls, including order operations, and receive correlated asynchronous responses. It can also subscribe to NT8 market data and P&L updates without repeatedly opening HTTP connections. See the current WebSocket API documentation for message types, rate limits, reconnection behavior, and Add-On requirements.

One boundary matters: CrossTrade does not currently expose a customer-facing Tradovate WebSocket. Linked Tradovate accounts use webhooks, the REST /v1/api/tv surface, or Tv_* MCP tools. Do not design around a Tradovate socket or an undocumented fill subscription.

Choose WebSocket when your own NT8 application benefits from a persistent channel for frequent RPC, live quote updates, or P&L events. If all you need is an occasional account read or order request, REST is simpler.

MCP: an AI client makes the calls

MCP, the Model Context Protocol, gives Claude, ChatGPT, Cursor, and other MCP-compatible clients typed tools. CrossTrade hosts its MCP server at https://app.crosstrade.io/v1/api/mcp.

The MCP documentation covers account reads, order tools, market analysis, NinjaScript authoring, compilation, backtesting through NinjaTrader's Strategy Analyzer engine, and strategy deployment. The model can choose a tool based on the conversation, which is why MCP uses OAuth scopes and a declared tool inventory instead of a webhook URL or hand-rolled REST integration.

MCP tool calls require an Elite subscription. NinjaTrader tools also require the CrossTrade NT8 Add-On v1.13.0 or higher. The Tv_* Tradovate tools need a linked Tradovate account but do not require NinjaTrader or the Add-On.

The safety model has two independent parts. The OAuth scope is the hard boundary: mcp:read cannot call write tools, while mcp:trade can. The prompt is the operating procedure: read current state, restate the proposed write, and wait for explicit confirmation. Use both. The documented MCP workflows and safety guide also recommends checking account, connection, positions, working orders, and relevant risk state immediately before a write.

Choose MCP when an assistant is genuinely part of the workflow: inspect the account, research or draft an action, show the exact account, contract, side, quantity, and order type, then execute only through the permission and confirmation gates you set.

How to choose in trader terms

• I only want a TradingView alert to place the trade. Use a webhook. Test one obvious simulation payload and verify Alert History plus broker state.
• I want my own script to run the workflow. Use REST.
• I need persistent RPC, live quotes, or P&L in my NT8 application. Use WebSocket.
• I want Claude, ChatGPT, or Cursor to handle part of the workflow. Use MCP with read scope by default and explicit write confirmation.
• I run multiple accounts. A trade copier is a separate product surface. Complete the pre-live verification checklist before enabling it on live or funded accounts.

If you need the developer-level architecture after making this trader-facing choice, read MCP vs REST vs WebSocket for NinjaTrader automation. For a deeper Tradovate-only surface comparison, see Tradovate API automation and WebSocket availability.

Learn More

One order intent, four surfaces

Suppose the intent is to place a one-contract MES buy limit order in simulation:

• Webhook: send a plain-text alert containing command=place, action=buy, order_type=limit, limit_price, and qty=1.
• REST: call the platform's documented place-order endpoint with JSON and a Bearer token.
• WebSocket: on NT8, send a PlaceOrder RPC message with a correlation ID and inspect the asynchronous response. Use documented state reads for reconciliation.
• MCP: ask the assistant to inspect state, restate the exact order, wait for confirmation, then call PlaceOrder for NT8 or Tv_PlaceOrder for Tradovate.

Same intent, four callers. Pick the caller that matches your workflow, not the interface with the longest feature list.

Start safe, then go live

Every path above can be tested with simulation or demo accounts. Start with the smallest complete workflow:

1. Confirm the destination, account, instrument, side, quantity, order type, and prices.
2. Send one test instruction.
3. Check the interface-level result: Alert History, REST response, WebSocket RPC response, or MCP transcript.
4. Verify the order in NinjaTrader 8 or Tradovate. Accepted is not the same as filled.
5. Test cancellation, closing behavior, and any protection you expect.
6. Move to live only after the simulation behavior matches the intended workflow.

Prop-firm rules are a separate boundary. Automation permission, copier permission, account stage, and supported platforms can differ by firm and can change. Confirm each point in the firm's current official rules before connecting an automated workflow. CrossTrade documents technical connection paths, not firm approval.

Frequently asked questions

Is a TradingView webhook the same as an API?

No. A webhook is a one-way message sent to a URL when an event occurs. A REST API is a set of endpoints your code calls and receives responses from. Webhooks are simpler for alert-driven execution; APIs give your application deterministic request-response control.

Can I use MCP with Tradovate?

Yes. CrossTrade's Tv_* MCP tools work with a linked Tradovate account and do not require the NT8 Add-On. MCP tool calls require an Elite subscription.

Does CrossTrade have a WebSocket for Tradovate?

Not currently. The CrossTrade WebSocket API is for NinjaTrader 8. Tradovate automation uses webhooks, the REST /v1/api/tv surface, or Tv_* MCP tools. Check the current WebSocket docs before designing around that boundary.

Do I need a VPS to automate TradingView to Tradovate?

No. CrossTrade routes eligible webhook orders to a linked Tradovate account through the cloud. NinjaTrader, a home computer, and a VPS do not need to stay online for that route. The TradingView-to-Tradovate no-VPS guide covers the complete setup.

Will MCP place orders without my confirmation?

It can place orders if the client has mcp:trade scope and its instructions allow the write. Confirmation is a workflow gate, not an automatic substitute for permissions. CrossTrade's documented safe pattern is to read current state, restate the proposed action, and wait for explicit confirmation before calling a trade tool.

Is automated trading allowed on prop firms?

It depends on the firm, account stage, platform, and current rules. Confirm automation and copier permission with the firm's official policy before connecting anything. Technical compatibility does not mean firm approval, and CrossTrade does not claim approval for any workflow.

Start with the interface that matches your workflow

Use a webhook for alert-driven orders, REST for your own code, WebSocket for persistent NT8 RPC and streams, and MCP for AI-assisted workflows with scoped permissions. Test the complete path in simulation, verify broker state, and expand only after the smallest workflow behaves as expected.

• Start with webhooks for Tradovate
• Explore the CrossTrade API
• Connect an AI client through MCP
• Start a free 7-day trial

CrossTrade is execution and automation software, not a broker, financial adviser, or trading strategy. Futures trading involves substantial risk. Automated and AI-assisted tools can produce or execute incorrect instructions. Test in simulation, supervise automated systems, and verify every order through the broker.

Start your free trial

Try CrossTrade for 7 days.

Sign Up