TLDR: A production TradingView webhook server needs a public HTTPS endpoint, a fast response, authentication, payload validation, a durable queue, duplicate protection, logs, monitoring, and broker reconciliation. TradingView only accepts destination ports 80 and 443, does not support IPv6 webhook targets, and cancels requests that take longer than three seconds. If your only goal is to automate an eligible TradingView strategy, UMT offers a browser-based alternative with no user-managed webhook server, JSON payload, or broker API keys.
Stop Executing Trades By Hand.
UMT Automator turns your TradingView or NinjaTrader strategy into automatic, hands-free execution — no code, no webhooks, no missed signals. Prefer a ready-made edge? Browse UMT's tested Strategies & Indicators built for both platforms.
Free 7-day trial on the Automator · No credit card required
A TradingView webhook server sounds simple: receive an HTTP POST and place a trade. In production, that single sentence hides the most important work. The receiver has to be public, fast, secure, observable, resilient to retries, and careful enough not to create duplicate orders.
This guide explains the minimum reliable architecture and the point at which using a no-webhook alternative may be the better business decision.
What TradingView Requires from a Webhook Endpoint
According to TradingView’s official documentation, a webhook alert sends an HTTP POST to the URL you provide. Several constraints affect server design:
- Only destination ports 80 and 443 are accepted.
- IPv6 webhook targets are not supported.
- If the remote server takes more than three seconds to process the request, TradingView cancels it.
- Valid JSON alert messages are sent with an
application/jsoncontent type; other messages usetext/plain. - Webhook use requires two-factor authentication on the TradingView account.
- TradingView warns that webhook delivery can occasionally fail.
Those rules mean the request handler should not wait for a broker API, database report, email, or complex strategy calculation before responding.
A Reliable TradingView Webhook Architecture
A safer production flow looks like this:
- HTTPS gateway: receives the public request on port 443 and terminates TLS.
- Authentication: verifies a secret path, token, signature design, or other expected credential without exposing broker secrets in the alert.
- Validation: checks the payload schema, allowed strategies, symbols, sides, quantity limits, and timestamp.
- Idempotency: creates a stable event identifier and rejects or safely ignores duplicates.
- Durable queue: records the accepted event before returning a fast success response.
- Execution worker: converts the approved event into the broker’s symbol and order format.
- Reconciliation: compares the submitted order with broker acknowledgments, rejections, cancellations, and fills.
- Monitoring: alerts the operator when delivery, queueing, authentication, or broker execution fails.
The key design principle is to acknowledge a valid event quickly and perform slower work asynchronously. A slow synchronous handler is a common cause of TradingView webhook timeouts.
Why Duplicate Protection Is Essential
A webhook receiver must assume that the same logical event can arrive more than once. TradingView documents limited resubmission behavior for certain server errors: it can resend after five seconds for HTTP 500–599 responses, except 504, up to three resends after the original request.
That behavior can improve delivery, but a server that submits an order and then returns an error may receive the event again. Without an idempotency key or durable event record, one signal can become multiple broker orders.
Do not solve this by blindly treating every repeated message as safe. Build a unique key from stable fields such as strategy, symbol, intended action, bar time, and a generated alert identifier. Store the decision before order submission and reconcile uncertain outcomes with the broker.
Authentication and Security
A public trading endpoint should never trust a request simply because it contains familiar JSON. At minimum:
- Use HTTPS with a valid certificate.
- Use a long, revocable secret or another authentication control.
- Validate allowed symbols, strategies, actions, and maximum quantity server-side.
- Apply rate limits carefully without blocking legitimate bursts.
- Restrict administrative access and protect logs.
- Keep broker credentials out of TradingView alert messages and URLs.
- Rotate credentials and document incident-response steps.
TradingView publishes webhook sender IP addresses and describes certificate-based receiver verification options. An IP allowlist can be one layer, but it should not be your only authorization control. Proxies, firewalls, and network changes can also turn an overly strict allowlist into a 403 error.
Payload and JSON Validation
Define a narrow schema rather than accepting arbitrary fields. A receiver might require an event ID, strategy name, symbol, action, quantity instruction, and event timestamp. It should reject missing, unknown, or out-of-range values before they reach the broker worker.
Remember that TradingView selects the content type based on whether the message is valid JSON. A missing quote, trailing comma, unescaped line break, or placeholder that expands unexpectedly can change how the server parses the request. Use the checklist in TradingView Webhook Invalid JSON when the receiver cannot parse the body.
Logging That Actually Helps
Useful logs connect the entire lifecycle without exposing secrets. Record:
- Arrival time and a correlation ID.
- Authentication and validation outcome.
- Sanitized strategy, symbol, side, and event time.
- Queue acceptance and worker start time.
- Broker request ID and normalized response.
- Order rejection, cancellation, partial fill, and final fill state.
Do not log passwords, API secrets, session cookies, or complete authorization headers. A status page should distinguish “webhook accepted,” “order submitted,” and “order filled.” Those are not the same outcome.
Testing Before Live Orders
- Send a known test payload outside market hours or to a non-trading test route.
- Test invalid authentication, malformed JSON, an unknown symbol, excessive quantity, and duplicate events.
- Simulate a slow broker API while confirming the webhook still responds within three seconds.
- Test queue failure and verify that the endpoint does not falsely return success.
- Use paper trading to test the complete order lifecycle.
- Confirm alert logs, server logs, and broker records can be correlated.
A successful HTTP response only proves that the endpoint responded. It does not prove that a broker accepted or filled an order.
The Real Cost of a Webhook Server
Hosting may be inexpensive, but ownership includes more than a monthly server bill. Someone must monitor certificates, dependencies, secrets, broker API changes, logs, alerts, security, retries, and recovery. If the system can submit financial orders, maintenance is part of the risk model.
A custom server can be appropriate for developers who need fully bespoke execution, many integrations, or server-side operation with every local browser closed. For a trader who simply wants to automate an eligible TradingView strategy, that stack can be more infrastructure than the goal requires.
A No-Webhook-Server Alternative
UMT Automator uses a browser-based approach with a supported broker connected inside TradingView. The user does not need to deploy a public webhook receiver, write JSON, maintain middleware, or provide broker API keys to UMT.
The tradeoff is operational: the required browser, TradingView tab, and internet connection must remain open and active. Broker and instrument availability also depends on TradingView’s broker connection and account permissions. Begin with paper trading and verify the entire workflow.
If maintaining an execution server is not how you want to spend your trading time, compare the UMT Trade Automator for TradingView with the broader TradingView webhook alternatives. A seven-day UMT trial is available through support@ultramegatrader.com.
Frequently Asked Questions
Can I run a TradingView webhook server on any port?
No. TradingView documents support for destination ports 80 and 443 only.
How fast must the server respond?
TradingView cancels a webhook request if the remote server takes longer than three seconds. Queue accepted work and respond quickly.
Will TradingView retry a failed webhook?
TradingView documents resubmission for HTTP 500–599 responses except 504, with three resends after the original request at five-second intervals. Do not treat this as guaranteed delivery; design duplicate protection and monitoring.
Do I need a webhook server to use UMT?
No. UMT’s browser-based workflow does not require a user-managed webhook endpoint or middleware server.
Does a 200 response mean the order filled?
No. It only means the HTTP request was handled successfully. Broker acceptance and fill status must be tracked separately.
