Check TradingView webhook delivery first
According to TradingView's webhook documentation, alerts are sent as HTTP POST requests. Valid JSON in the alert message uses the JSON content type; other message text uses a plain-text content type. Confirm the receiver accepts the format you actually send.
- Enable two-factor authentication. TradingView requires it for webhook alerts.
- Confirm the alert fired. Check the alert log and the selected alert condition. A condition that has not triggered produces no webhook request.
- Check the exact endpoint. Use the receiver's public HTTPS URL, including its path. A private LAN address or localhost URL is not a public receiver.
- Check the port and network. TradingView accepts webhook ports 80 and 443 and currently does not support IPv6 webhook delivery. Ensure the endpoint has a working compatible public network path.
- Keep the response fast. TradingView cancels requests when the remote server takes longer than three seconds to process them.
- Inspect the receiver's request log. Record arrival time, HTTP status and event ID without logging credentials. A firewall, invalid TLS setup or wrong path can prevent the request from reaching the application.
For network restrictions and any IP allowlist, use the current values in TradingView's official webhook reference rather than copying an old list from a blog.
Use a JSON test message before testing orders
Agree a test action with the bridge developer and verify it records an event without placing an order. The example below is a proposed bridge-specific schema, not a built-in TradingView or MT5 command. Change it to match the receiver; use a fresh timestamp if the receiver checks message age.
{
"event_id": "demo-signal-001",
"action": "test",
"symbol": "EURUSD",
"sent_at": "2026-10-01T12:00:00Z"
}The receiver should validate permitted actions and symbols and use a dedicated authentication mechanism. Keep broker account credentials out of alert messages. Log a rejected test as a rejected test rather than silently converting it into a trade.
Recommended receiver design: acknowledge accepted events quickly
Do not make the incoming HTTP request wait for MT5 to finish execution. Our recommended design validates the request, records an accepted event durably and then returns a success response promptly. A worker or terminal-side receiver processes the accepted event separately.
Return success only after acceptance has been recorded. If storage or the queue fails, report the failure instead of dropping an event behind a successful response. An HTTP 200 or 202 acknowledgement means the bridge accepted a request; it does not prove a broker fill.
Maintain states such as received, rejected, queued, submitted and completed. Store the broker result against the same event ID. Make event handling idempotent so a repeated accepted event returns its recorded result rather than creating another order.
TradingView-to-MT5 troubleshooting by symptom
| Symptom | Where to look | Next diagnostic step |
|---|---|---|
| No alert event | TradingView condition and alert log | Confirm the intended condition, symbol and timeframe; check whether the setup occurred. |
| Alert exists, no receiver request | Endpoint, TLS and firewall | Verify the public URL, supported port and compatible network path. |
| HTTP 400 | Payload validation | Compare required fields, JSON syntax and content type with the bridge schema. |
| HTTP 401 or 403 | Authentication or access policy | Check the bridge-specific credentials and any firewall rule; inspect the server's reason. |
| HTTP 404 | Webhook route | Check the exact endpoint path and deployed application route. |
| Delivery timeout | Receiver response time | Move slow execution to a worker after durable acceptance; measure response time. |
| Accepted, no MT5 order | Queue, receiver and trade result | Trace the event ID through terminal connectivity, permissions and broker retcode. |
| Two orders for one signal | Event identity and idempotency | Replay the same event ID and check that only one execution can be created. |
The HTTP statuses above are common diagnostic conventions. A particular bridge may use different responses; its request log and documented schema take precedence.
When the webhook arrives but MT5 does not trade
Confirm the receiver is connected to the intended terminal and account. Check Algo Trading permissions, the exact broker symbol, the selected volume, stop prices and the broker's trade return code. A TradingView symbol name may need an explicit mapping to a broker symbol suffix.
If the MT5 receiver pulls events with MQL5 WebRequest(), allow the bridge server URL in terminal options. This function is synchronous, is available to EAs and scripts, and cannot run in the Strategy Tester. Test the live network transport separately from strategy logic.
Six tests for a custom TradingView-to-MT5 bridge
- Send a supported test event and confirm it is recorded without creating a trade.
- Send malformed JSON or an unknown action and confirm an explicit rejection.
- Replay one event ID and confirm it cannot create two executions.
- Disconnect the receiver and verify events remain traceable with a documented expiry policy.
- Restart the bridge and verify accepted events and broker results can be reconciled.
- Test a permitted order on a demo account and record alert time, receiver time, broker response and final order state.
Agree these tests before development. For a custom bridge, the deliverable should include the payload schema, authentication setup, symbol mapping, restart behavior and a log that follows each event through execution.
Discuss a TradingView-to-MT5 bridge
Official documentation
The platform facts and error-code definitions above are based on these primary references. The diagnostic workflow and bridge design are our implementation recommendations.