Your AI-built bridge just did what you asked. A TradingView alert fired, your code received the webhook, and a position opened on your MetaTrader 5 demo account. That single trade proves one thing: the happy path works once, under conditions you controlled. It does not tell you what happens when TradingView sends the same alert twice, when your process restarts mid-order, or when the broker rejects a request and your code assumes it went through.
This article sets out nine tests to run before that bridge touches a live account. Each follows the same shape: the condition that can occur, the consequence if the code is not ready for it, a safe way to test it on a demo account, and who is responsible for the outcome. These are proposed tests for you to run. We have not run them against any particular tool, and passing them is not something any connector, PineConnector included, should be assumed to do without evidence.
Who this is for: anyone who has used ChatGPT, Claude or another assistant to build a webhook-to-MT5 connector and wants to know what "working" should mean before real money is involved. If you have no interest in operating your own bridge, the same nine questions are what you should ask of any connector vendor before you sign up.
Why one successful trade is weak evidence
A trading bridge sits between two systems that make no promises to each other. TradingView delivers alerts on a best-effort basis and says plainly that webhooks "may occasionally fail to reach the specified URL"[1]. MetaTrader, at the other end, returns a result structure for every order request, and its own documentation has the calling code check the return code rather than assume success[2]. Everything interesting happens in the gap between those two facts. A single test trade exercises none of it.
Anthropic's guidance for working with AI-generated code makes the same point from the other side: give the model "a check it can run", because without one "looks done" is the only signal available[3]. The nine tests below are that check, translated into trading infrastructure.
Test 1: The same alert arrives more than once
Condition. TradingView's resubmission policy states that if your endpoint "returns an HTTP response status code between 500 and 599 (except for status code 504)", the notification "will be sent again after 5 seconds", and that "the maximum number of webhook sends for one trigger can be 4"[4].
Consequence. If your code opened a position and then crashed while writing the log, returning a 500, the same instruction can arrive up to three more times. Whether that produces up to four positions depends entirely on how your receiver identifies a repeated message. That consequence is an engineering inference from TradingView's documented behaviour, not something TradingView states.
Test. On a demo account, send one alert and have your endpoint deliberately return a 500 after processing it. Wait thirty seconds. Count the positions on the terminal, not the log lines in your bridge.
Do not assume that every retry produces a duplicate, or that any connector prevents it. Look at the orders.
Test 2: Your code takes too long to answer
Condition. TradingView cancels the request if "a remote server takes longer than three seconds to process a request"[1].
Consequence. A bridge that waits for the broker's fill before replying will be cancelled on a slow day. What your code does after the cancellation, and whether it treats the cancelled request as never received, is the question.
Test. Add an artificial four-second delay before your response and fire an alert. Check whether the order was still placed, whether TradingView marked the alert as failed, and whether a retry followed.
Do not assume that a fast reply and a placed order are the same event. They are two separate stages, and the reply should acknowledge receipt only.
Test 3: The process restarts with work pending
Condition. A dependency update, a crash, a host reboot. Your bridge stops between receiving an instruction and confirming the broker's result.
Consequence. Anything held only in memory is gone. The alert may have been acknowledged to TradingView and never acted on, or acted on and never recorded.
Test. Fire an alert and kill the process the instant it logs receipt. Restart it. Inspect what it does with the half-finished work: replays it, drops it, or does not know it existed. Then compare against the terminal.
Do not assume that "it restarts automatically" means it recovers correctly. Restarting is a process-supervisor feature. Reconciliation is code you have to write.
Test 4: A valid instruction points at the wrong place
Condition. Two MT5 accounts on one machine. A symbol that is XAUUSD at one broker and GOLD at another. A volume field that one broker reads in lots and your script filled in units.
Consequence. The order succeeds. It is simply not the order you meant, on the account you meant.
Test. Write down the expected result before sending: account number, server, symbol, direction, volume, stop and target. Send the alert. Compare every field of the resulting order against the list. PineConnector's own syntax makes the order of fields mandatory, "License ID, then Command, then Symbol, then any Other parameters"[5], precisely because a misplaced field is a valid-looking message with a different meaning.
Do not assume that a filled order is the intended order.
Test 5: The broker says no
Condition. MetaTrader's trade server answers every request with a return code. The documentation lists dozens, including "Request rejected", "There is not enough money to complete the request", "Invalid volume in the request", "Market is closed" and "Request canceled by timeout"[6].
Consequence. Code that checks only that the request was sent, rather than that the result code equals the "Request completed" value, will report success for a rejected trade. MetaQuotes' Python example does exactly this check, and its order_check documentation adds that "successful sending of a request does not entail that the requested trading operation will be executed successfully"[7].
Test. On the demo account, request a volume the account cannot afford, then a volume below the symbol's minimum, then an order while the market is closed. Confirm your bridge records the specific return code each time and does not mark the trade as open.
Do not assume a pre-flight check guarantees the fill. It only rules out some failures in advance.
Test 6: The broker accepted, but you never heard back
Condition. The order request reaches the terminal and the broker fills it, but the connection between your code and the terminal drops before the result comes back.
Consequence. Your code sees a timeout. The naive fix, retrying, now places a second order that the broker also fills.
Test. Simulate an uncertain response by interrupting the connection to the terminal immediately after sending. Before allowing any retry, have the code query open positions and pending orders and reconcile against what it intended. Only then decide.
Do not assume that blind resubmission is safe. A lost response is not a rejected order.
Test 7: Secrets in the message, the source, or the log
Condition. TradingView's own guidance is to "ensure that you don't include sensitive information such as login credentials or passwords in the webhook body"[1]. AI-generated scaffolding often reads credentials from wherever is quickest, and logs whatever it received.
Consequence. A broker password in a webhook body travels through TradingView's servers and lands in your access log. A credential in a source file ends up in version control.
Test. Using dummy credentials, search the repository, the alert message template, the running configuration and every log output for the dummy values. Anything found is a leak path.
Do not assume that AI-generated or open-source projects necessarily expose secrets. Many do not. Check yours.
Test 8: You changed the script, but the alert did not
Condition. TradingView's Pine Script documentation explains that creating an alert "saves a 'snapshot' of the script, its inputs, and the current chart's context on TradingView's servers", and that subsequent "changes to the script, its inputs, or the user's chart do not affect that created alert"[8]. The documented remedy is to "delete the existing alert and create a new one".
Consequence. This one is upstream of your bridge and no hosting arrangement can fix it. The bridge faithfully executes an instruction generated by last week's logic.
Test. Change a visible input in the script, such as the lot size in the alert message. Trigger the old alert. Confirm that the old value arrives. Then recreate the alert and confirm the new one does.
Do not assume that a saved chart means a current alert.
Test 9: It breaks at 3am and you are asleep
Condition. Every one of the previous eight scenarios, happening when nobody is watching.
Consequence. The difference between a five-minute incident and a five-hour one is detection and a written recovery procedure.
Test. Answer three questions in writing. How would you learn the bridge has stopped, other than by noticing missing trades? Who restarts it, and how? What is the first command you run to reconcile the terminal against what should have happened?
Do not assume that paying a provider makes this disappear. A managed service moves the hosting and restart responsibility to the provider. It does not review your alert logic, and it does not know what trade you intended.
The verification checklist
This is the pass or fail list for every test above. It applies to a bridge you built, a free connector you downloaded, and a paid product such as PineConnector alike. Where a vendor's documentation does not answer an item, ask their support before assuming the answer.
| Check | Evidence that counts | Evidence that does not count |
|---|---|---|
| The expected trade exists | An open position or order on the terminal matching your written expectation | A log line saying "order sent" |
| On the intended account | Account number and server name on the position match your list | The bridge was "configured for" that account |
| Correct symbol, direction, volume, stops | Each field compared individually against the expectation | "It opened a trade" |
| No unintended duplicates | Position count after Tests 1, 2 and 6 equals the number you intended | The alert fired once in TradingView |
| Result code recorded | The MT5 return code and comment stored per instruction, including rejections | An HTTP 200 returned to TradingView |
| Recovery after restart | Documented behaviour for in-flight work, verified in Test 3 | The process is running again |
| No secrets in transit or at rest | Dummy credentials not found in messages, source, config or logs | "We use environment variables" |
| Alert reflects current script | Recreated after the last script change | The chart looks right |
| Someone is responsible at 3am | Written detection method and recovery steps | Auto-restart is enabled |
Where PineConnector Edge fits, and where it does not
Two of the nine tests are about keeping a terminal alive: Test 3 and Test 9 both get harder when the MT5 terminal itself is the thing that restarts or goes offline. That is the part PineConnector Edge, PineConnector's managed MT5 hosting, takes on. PineConnector runs the MetaTrader 5 terminal on its own infrastructure. What that means for your evidence today, according to the Edge Guide[9]:
- Supported now. Instance Settings has controls "for manually restarting or terminating your Edge MT5 instance". The Bridge page lets you "send test signals and view their processing results, including the reported latency". So Tests 1, 2, 4 and 8 can be run against a hosted terminal using Bridge test signals and the positions on your broker account.
- Not available in early access. "Trading account data, including account balance, and the Experts and Journal logs are not yet available." Evidence for the terminal stage therefore comes from portal status, Bridge test-signal results and your broker's own account view, not from reading terminal logs in the portal.
- Planned, not editable today. "EA settings currently use a fixed default configuration and cannot be edited." If your test plan depends on changing EA settings, that is a future capability.
The product page puts the boundary in one sentence: "Edge is managed infrastructure, not managed execution", and "you remain responsible for what that terminal is told to do"[10]. In the language of this article, Edge changes who answers Test 9's "who restarts it" question for the terminal. It does not answer Tests 1, 2, 4, 5, 6, 7 or 8 for you, and its own behaviour on duplicate delivery and restart reconciliation is something to confirm with PineConnector's documentation or support rather than assume, exactly as you would with any provider. Edge is also PineConnector's connector only, MT5 only, with instances in New York now and London planned for Plus and Pro. A bridge you wrote yourself cannot be hosted on it.
Plans, with hosting included, are Core at $59 a month for one connection and one hosted MT5 instance, Plus at $129 for three, and Pro at $199 for five.
Frequently asked questions
Do I really need all nine tests for a small personal bot?
Tests 1, 4, 5 and 8 cover the failures that produce wrong or duplicate orders on an otherwise healthy day. Start there. The rest cover what happens on a bad day, and a live account will eventually have one.
Can I run these against a paid connector instead of my own code?
Yes, and you should. Tests 1, 2, 4, 5 and 8 need only a demo account and a TradingView alert. For Tests 3 and 6 you need the vendor's documentation or support to explain their behaviour, since you cannot restart their process yourself.
Does PineConnector pass these tests?
This article does not claim that. PineConnector publishes its command syntax and an Edge Guide, both cited above, and those pages do not describe duplicate handling or restart reconciliation. Ask support the specific question and keep the answer with your test notes.
Is an AI assistant a bad way to build a bridge?
No. It is a fast way to produce a first version. The tests exist because a first version, however produced, has only been shown to work once.
Next step: if you decide operating the terminal is not the part you want to own, read what PineConnector Edge is and who it suits, and check the Edge Guide for current early-access scope before relying on any feature. If you are keeping your own bridge, the TradingView to MT5 setup guide covers the terminal side, and this explainer covers why the terminal is the component that has to stay online.
Reviewed 9 September 2026. Facts and prices were checked against the linked sources on that date.
Sources
- TradingView Help Center – How to configure webhook alerts, accessed 9 September 2026.
- MetaQuotes – MetaTrader 5 Python integration: order_send, accessed 9 September 2026.
- Anthropic – Claude Code best practices: Give Claude a way to verify its work, accessed 9 September 2026.
- TradingView Help Center – Webhook resubmission, accessed 9 September 2026.
- PineConnector Docs – Syntax, accessed 9 September 2026.
- MetaQuotes – MQL5 Reference: Trade server return codes, accessed 9 September 2026.
- MetaQuotes – MetaTrader 5 Python integration: order_check, accessed 9 September 2026.
- TradingView – Pine Script documentation: Alerts FAQ, accessed 9 September 2026.
- PineConnector Docs – Edge Guide (Early Access), accessed 9 September 2026.
- PineConnector – PineConnector Edge: managed MT5 hosting, accessed 9 September 2026.
PineConnector executes the instructions you send it. It does not select trades, manage money, or hold funds. Trading carries risk, and past performance of any strategy does not indicate future results.
