Tradovate API Automation: REST, Webhooks, MCP, and WebSocket Availability
Compare CrossTrade webhooks, REST, MCP, and WebSocket availability for Tradovate. Three cloud paths are supported; public WebSocket remains NT8-only.
CrossTrade offers three public ways to automate a linked Tradovate account: TradingView webhooks, the Tradovate REST API, and hosted MCP tools. CrossTrade also has a WebSocket API, but that endpoint is for NinjaTrader 8 only. It does not expose Tradovate accounts or the Tv_* tool surface.
That distinction matters when you choose an architecture. A TradingView alert, an application request, and an AI tool call can all reach Tradovate through CrossTrade's cloud. A public streaming client cannot, at least not through the current CrossTrade WebSocket endpoint.
This guide compares the four interfaces, explains where each one runs, and shows how their authentication, audit trails, controls, and rate limits differ.
The short answer
| Interface | Tradovate support | Best fit | Requires NT8 |
|---|---|---|---|
| TradingView webhook | Yes | Alert-driven order execution | No |
REST /v1/api/tv | Yes | Application request-response workflows | No |
MCP Tv_* tools | Yes | AI clients with scoped tools | No |
WebSocket /ws/stream | No | NT8 RPC, quotes, and P&L streams | Yes |
CrossTrade does maintain server-side broker connections and real-time Tradovate synchronization internally. Those internal connections power product features, but they are not a customer-facing Tradovate WebSocket API.
One linked account, three public paths
All three public Tradovate paths start with the same prerequisite: link a Tradovate Demo or Live identity under My Account > Brokers. After that, the interface determines how the instruction arrives and how you authenticate it.
1. TradingView webhooks
Use a webhook when TradingView owns the signal. The alert posts a CrossTrade command to your permanent webhook URL, and destination=tradovate; selects the cloud Tradovate route.
key=your-secret-key;
command=place;
account=DemoAccount;
instrument=ES1!;
action=buy;
qty=1;
order_type=market;
tif=day;
destination=tradovate;This path is available on Standard, Pro, and Elite. It does not require NinjaTrader 8, the CrossTrade Add-On, or a VPS.
Webhooks are the only one of these Tradovate interfaces that create webhook Alert History rows. Each attempt records its resolved destination. A green Tradovate row means accepted by the broker, not necessarily filled or finally resting. CrossTrade can add a later warning if an ordinary placement is subsequently rejected.
Webhook processing includes alert-specific controls such as secret validation, trade windows, news lockout where configured, webhook rate controls, per-account and instrument serialization, and Alert History. It also applies shared Tradovate controls such as Account Manager locks, position gates, Strategy Sync, and Trade Copier fan-out where applicable.
Choose webhooks when the event starts in TradingView and a human-readable alert audit trail is important.
2. Tradovate REST API
Use REST when your own application needs a deterministic request-response interface. Tradovate routes live under:
https://app.crosstrade.io/v1/api/tvREST uses the same CrossTrade bearer authentication as the broader API and requires API access on an eligible Pro or Elite plan. The linked Tradovate account is still the broker credential boundary. Your application does not send a Tradovate password to an order endpoint.
A simple account snapshot is a GET request:
GET /v1/api/tv/accounts/snapshot
Authorization: Bearer <token>A market order is a POST request:
POST /v1/api/tv/accounts/DemoAccount/orders/place
Authorization: Bearer <token>
Content-Type: application/json
{
"instrument": "MES1!",
"action": "buy",
"qty": 1,
"orderType": "market"
}The REST surface includes reads for link status, accounts, snapshots, positions, orders, order lifecycle, fills, balances, margin, contracts, exchanges, and Account Manager watermarks. It also supports placement, cancellation, change, cancel-and-replace, close, flatten, reverse, and bracket workflows.
REST mutations share CrossTrade's Tradovate validation, Account Manager locks, position gates, and configured copier fan-out. They do not inherit every webhook-only layer. Direct API calls do not use a webhook secret, do not create Alert History rows, and do not pass through the webhook news lockout or webhook request bucket.
REST also differs from webhook grammar in a few important ways. Direct REST take-profit and stop-loss values are absolute prices. Named Tradovate ATM templates are a webhook convenience; REST exposes the equivalent inline atm* fields.
Choose REST when you own the application logic, tests, retries, reconciliation, and operator interface.
3. Hosted MCP tools
Use MCP when an AI client needs structured access to the account. CrossTrade exposes Tradovate reads and writes as typed tools such as:
Tv_Status,Tv_ListAccounts, andTv_AccountSnapshotTv_GetPosition,Tv_ListOrders, andTv_GetOrderLifecycleTv_PlaceOrder,Tv_ChangeOrder, andTv_CancelReplaceTv_ClosePosition,Tv_Flatten, andTv_Reverse
The hosted MCP server uses Streamable HTTP at:
https://app.crosstrade.io/v1/api/mcpMCP requires CrossTrade Elite and uses its own OAuth consent and token flow. A normal REST bearer token is not the MCP credential. Read tools require mcp:read; trade tools require mcp:trade. CrossTrade filters the tool inventory by scope.
Underneath the tool call, Tradovate trade operations use the same cloud dispatcher and shared controls as REST. Direct MCP orders do not create Alert History rows. Use the returned order ID, Tv_GetOrder, and Tv_GetOrderLifecycle to verify broker state.
Choose MCP for interactive, human-supervised work with an AI client. Use read scope by default and require an exact account, environment, contract, side, quantity, and order summary before any write tool.
Where WebSocket fits, and where it does not
The CrossTrade WebSocket endpoint is:
wss://app.crosstrade.io/ws/streamIt supports NinjaTrader 8 RPC calls, NT8 market-data subscriptions, and NT8 P&L streaming. Requests pass through the CrossTrade Add-On running inside a connected NinjaTrader instance. The current endpoint cannot call /v1/api/tv routes and does not accept Tv_* tools.
In practical terms:
- You cannot subscribe to a linked Tradovate account through CrossTrade's public WebSocket endpoint.
- You cannot place a Tradovate order by sending a WebSocket RPC message.
- You cannot use a Tradovate broker login as the data source for the NT8 quote stream.
- You must use REST, MCP, or webhooks for public Tradovate automation through CrossTrade.
For NT8, WebSocket remains useful when an application needs a persistent connection for Add-On RPC, quote updates, or P&L events. It requires NinjaTrader 8 to be open, the Add-On to be connected, and a compatible Add-On version.
What to use instead of a Tradovate WebSocket
The right replacement depends on what you were trying to stream.
Account and order dashboard
Use GET /v1/api/tv/accounts/snapshot for a shaped view of balances, open positions with P&L, and working orders. Poll at a sensible interval and back off when the dashboard is not visible. Do not create a tight loop that assumes every broker field changes on every request.
Single-order reconciliation
Use the order endpoint and order lifecycle endpoint. The lifecycle response includes submitted commands and command reports, including broker rejection text. This is more useful than blind repeated placement when a result is uncertain.
Human and AI session
Use the MCP read tools for an on-demand snapshot. MCP is not a market-data streaming transport, but it gives an agent structured account context without custom REST client code.
TradingView strategy event
Use a webhook. TradingView already owns the event, so maintaining a separate persistent socket would not improve the source signal.
Authentication is not interchangeable
| Surface | Authentication | Permission model |
|---|---|---|
| Webhook | Permanent webhook URL plus CrossTrade secret in the message | Subscription, account controls, command fields |
| REST | CrossTrade API bearer token | API plan entitlement and endpoint validation |
| MCP | MCP OAuth or MCP credential | mcp:read or mcp:trade |
| WebSocket | CrossTrade API bearer token | NT8 RPC allowlist and connected Add-On |
Do not put a REST token in a TradingView alert. Do not paste a webhook secret into an AI chat. Do not assume a completed Tradovate link grants MCP trade scope. Keep each credential attached to one intended interface.
Audit trails and verification
The word “success” has different operational meaning depending on the surface:
- Webhook: Inspect Alert History and then verify the order in Tradovate. Green means accepted, not filled.
- REST: Record the response, duration, account, instrument, and order ID in your application logs. Reconcile with the order lifecycle endpoint.
- MCP: Keep the client transcript and use Tradovate order tools to verify the result.
- WebSocket: For NT8 only, correlate asynchronous RPC responses by request ID and resubscribe after reconnecting.
CrossTrade deliberately avoids blindly resending an ambiguous Tradovate mutation. Your integration should do the same. Read broker state before deciding whether a retry is safe.
Rate limits and retries
Authenticated CrossTrade API traffic uses a smooth 3 requests-per-second refill with a burst allowance of 20, commonly described as 180 requests per minute. REST, MCP, and NT8 WebSocket RPC share the authenticated API budget for a user. Webhook submissions use separate controls.
Tradovate can also impose its own dynamic broker penalty window. CrossTrade reports that separately as broker_rate_limited. Do not claim or design around a fixed Tradovate requests-per-minute number. When either layer returns a rate-limit response, honor Retry-After and reduce request pressure.
Composite commands can require multiple broker calls, especially when they cancel orders, poll for settlement, add protection, or fan out through a copier. One user action is not always one downstream request.
GA and beta boundaries
Tradovate-native webhook routing, the /v1/api/tv REST surface, the API Playground, and hosted Tv_* MCP tools are generally available. Native orders, broker-hosted brackets, multibrackets, fixed stops, and triggerless continuous trailing are also GA.
CrossTrade-managed target-fill breakeven and profit-triggered trail activation remain beta. Fill-driven Tradovate copying also remains beta. Check the current documentation before building around an advanced managed feature.
Choose by the owner of the event
- If TradingView owns the signal, use a webhook.
- If your application owns the workflow, use REST.
- If a human working with an AI client owns the session, use MCP.
- If you need CrossTrade WebSocket RPC or streaming, that is currently an NT8 architecture, not a Tradovate one.
Start with one interface. Link a Demo identity, make the smallest read or test order possible, and build reconciliation before adding concurrency or autonomous writes.
For endpoint details, use the Tradovate API reference. For AI clients, use the Tradovate MCP tools guide. For TradingView routing, use the destination compatibility matrix. The WebSocket documentation is the source of truth for the NT8-only streaming surface.

CrossTrade is execution and automation software, not a broker, financial adviser, or trading strategy. Futures trading involves substantial risk. Test in simulation, supervise automated systems, and verify every order through the broker.