TradingView Webhook Limits, Retries, and the 3-Second Timeout

These are transport rules, not execution guarantees. An alert can trigger successfully while the request fails at DNS, TLS, routing, receiver validation, broker authorization, or order placement. Conversely, a sender timeout does not prove that the receiver performed no work. The receiver may have accepted the body and continued processing just as the sender stopped waiting. That uncertain boundary is why a trading webhook must be traceable and duplicate-safe rather than built around the assumption that one chart event always equals one request and one order.

TradingView also states that IPv6 is not currently supported for webhooks and publishes sender IP addresses for receivers that need allowlisting. Treat the official support page as the current authority because infrastructure constraints can change. Do not copy an address list into a permanent firewall rule without a review process. For a hosted HexTrade endpoint, follow the private URL supplied in Accounts instead of adding an unsupported port, proxy redirect, or self-invented authentication query.

The correct design depends on the receiver, but the boundary must be explicit. A fast `2xx` might mean accepted for processing rather than filled. If so, logs and callbacks must preserve the later broker result, and the operator must not read the HTTP response as execution proof. A `4xx` should represent a caller-correctable problem such as invalid data or access. A `5xx` should represent a server-side failure only when inviting TradingView's documented resend is safe for that request.

Slow DNS, TLS handshakes, redirects, overloaded application code, and synchronous dependency calls all consume the deadline. Redirecting to a login page is especially harmful because TradingView reports it as a 3xx delivery problem, not as an authenticated trade. Test the exact URL entered in the alert, from a public network path, with a realistically sized body. For HexTrade, use the generated endpoint directly and keep it private rather than placing an unnecessary redirect in front of it.

A status code is therefore part of the control plane. Returning `500` for malformed JSON can multiply a permanently invalid message into four deliveries. Returning `200` before preserving accepted work can lose an instruction if the process fails immediately afterward. Returning `400` for a temporary internal outage prevents the documented 5xx retry path. There is no universal implementation, but each code must be selected according to whether resubmission is useful and safe, not according to a generic error handler.

The exception for 504 matters. Although 504 sits inside the 5xx range, TradingView explicitly excludes it from webhook resubmission. A receiver or proxy that emits 504 cannot assume TradingView will try again. Likewise, the official three-second cancellation can create ambiguity without any HTTP status reaching the sender. Monitor TradingView's Webhook status column and your receiving system together; either side alone can show only part of the transaction.

Create a fingerprint from stable event data that remains identical across resends: strategy or alert version, destination account, symbol, action, quantity, and an event time or sequence chosen by the signal producer. Do not base it on the receiver's arrival timestamp because every resend arrives at a new time. TradingView supports time placeholders, and HexTrade documents labels such as `strategyName`, `alertName`, `note`, and `tags`; those can improve human correlation, but do not invent an undocumented idempotency field for a product endpoint.

Idempotency also needs a state model. `received`, `validated`, `submitted`, `accepted`, `rejected`, and `unknown` are not interchangeable. If the first attempt reached a broker but the acknowledgement was lost, submitting again may create a second order. Hold an `unknown` event for reconciliation rather than treating it as failed. HexTrade's documented cooldown and quantity controls can limit some repeated activity, but they are guardrails with stated scope, not proof of a durable global idempotency guarantee.

Content type follows syntax. One trailing comma, unescaped quote, or malformed dynamic value can cause TradingView to send `text/plain`; a receiver expecting JSON may then return 4xx. That failure will not enter the documented 5xx retry path. Capture a rendered non-sensitive example and parse it before launch. Where a field can contain arbitrary text, constrain its alphabet or escape it correctly rather than assuming strategy labels can never include a quotation mark.

TradingView's security guidance is direct: do not send credentials in webhook URLs or messages. Authentication should be represented by the receiver's secure endpoint design, not by copying a broker password into Pine. HexTrade supplies a private webhook URL in Accounts and advises regeneration if it leaks. Use the exact HTTPS URL as documented, enable 2FA at TradingView, and restrict who can view or edit the alert configuration.

Separate transport testing from broker testing. A purpose-built test endpoint can prove sender behavior without exposing an account, while HexTrade's `dryRun` can validate its planned trade without placing one. Do not deliberately force server errors against a live order route unless the service explicitly supports that test. The goal is to verify your assumptions about statuses and duplicates, not to manufacture uncertain broker submissions.

After the transport matrix passes, run one smallest-size end-to-end test in an appropriate market session. Save the alert time, Webhook status, sanitized body fingerprint, receiver record, broker order identifier if available, and final state. Pause if any layer is missing or contradictory. Limits are easiest to manage when evidence is assembled before an incident; under pressure, an unexplained timeout often tempts operators into a dangerous manual resend.