You asked an assistant for "a webhook server that takes TradingView alerts and places trades on MT5", and it gave you a folder of files that runs. The question now is not whether the code works once. It is whether you can read it well enough to know what it will do on the day something is different: a repeated alert, a rejected order, a reboot at 3am. This article is a review walkthrough for someone who is not a professional developer. It shows what to open, what to look for, and what to ask, without giving you a trading script to paste in.
It applies to a project generated by ChatGPT, Claude or any other assistant, and to code a friend wrote. It also applies, in a different form, to software you cannot read. If you use a commercial connector such as PineConnector, you cannot review its source, so the last section turns each check into a question for the vendor instead. For why generating code and operating a service are different jobs, see Can ChatGPT or Claude build a TradingView-to-MT5 bridge?. For the demo-account tests to run after the review, see the nine tests to run next.
Who this is for, and who should skip it
This is for traders who have a generated project and intend to run it themselves, on a Windows machine or VPS, against a demo account first. If you do not want to own code at all, the review still matters, but as a set of vendor questions, so jump to the last section. If you are a professional developer, you already do most of this; the useful part for you is the trading-specific checks in steps three to five.
Step 1: Dependencies and where the code expects to run
Open the requirements file or the import lines. Two things matter. First, are versions pinned? A file that says MetaTrader5 with no version will install whatever is current on the day you deploy, which may not be what the assistant tested against. Second, does the project understand where MT5 lives? MetaQuotes describes its Python package as designed for "obtaining of exchange data via interprocessor communication directly from the MetaTrader 5 terminal"[1]. In plain terms, the package talks to a running MT5 terminal on the same Windows machine. A project that installs the package on a Linux server with no terminal will import cleanly and fail at the first call. If the project instead uses an Expert Advisor inside MT5, check that the EA file, its settings and the "Allow DLL imports" requirement are documented rather than assumed.
What to look for: a pinned version for every package, a README that says "run this on the same Windows machine as MT5", and no hidden assumption that the terminal is always logged in.
Step 2: Where the secrets are
Search the project for the words "password", "login", "token" and "secret". You are looking for three bad places. In the webhook body: TradingView's own guidance is "Don't include sensitive information such as login credentials or passwords in the webhook body"[2], yet generated examples sometimes put an account password in the alert message to select the account. In source files: a broker password typed into a Python file will end up in every backup and every paste you send someone for help. In logs: a line that prints the incoming request "for debugging" prints whatever was in it.
What good looks like: credentials come from environment variables or a secrets file that is excluded from version control, the webhook message carries an identifier (a licence ID or a name), not a password, and the logging line prints the parsed instruction, not the raw request.
Step 3: Does it read the broker's answer?
This is the check most generated projects fail quietly. MetaQuotes' documentation for the order-sending call is explicit: "Successful sending of a request does not entail that the requested trading operation will be executed successfully"[3]. The call returns a result structure with a return code, and the documented pattern compares that code against the "done" value before treating the order as placed[4]. MetaQuotes also provides a separate pre-flight check, described as "Check funds sufficiency for performing a required trading operation"[3], which validates margin and fields without placing anything.
Look for the line after the send call. If the code sends the request and immediately returns "OK" to TradingView, it is reporting that it tried, not that anything happened. In shape, the good version reads:
result = send_order(request)
if result.retcode != DONE:
log("rejected", result.retcode, result.comment)
# do not report success
That is a shape, not a program. The exact names come from the library your project uses; the point is that a rejection code has somewhere to go.
Step 4: Is the instruction checked against what you meant?
A valid order on the wrong account is still a wrong order. Trace how the project decides four things: which account or terminal receives the instruction, which symbol name it sends, which direction, and what volume. Broker symbol names differ; PineConnector's own test page warns that "You must use the symbol format specific to your broker" and that "Using the wrong symbol is a common reason for trades not executing"[5]. In generated code, look for a mapping table or a validation step. If the code passes the alert's symbol straight through with no check, an alert for one instrument can silently target a different one on a broker with suffixes.
What good looks like: an allow-list of symbols the project may trade, a volume ceiling, an explicit account selector, and a rejection path for anything outside them.
Step 5: What happens when the same alert arrives twice?
TradingView documents that if a webhook receives a server error response, the request is "sent again after 5 seconds", and that the "maximum number of webhook sends for one trigger can be 4"[6]. The engineering inference, and it is an inference rather than something TradingView states, is that a receiver which processes the order and then returns a 5xx error can cause the same trigger to be processed up to four times. Look for anything that recognises a repeat: an alert identifier stored for a few minutes, a timestamp comparison, or a rule that a second identical instruction within a window is ignored. If there is nothing, the project relies on never returning an error after placing an order, which is a fragile promise.
Step 6: Does it answer TradingView in time?
TradingView states that "If a remote server takes longer than three seconds to process a request, the request will be cancelled"[2]. A project that waits for the broker's fill before responding will sometimes exceed that on a slow day, and the cancelled request may then be resent. Look at the order of operations: does the handler acknowledge receipt first and place the order after, or does it do everything inside the request? Either can be made to work, but the second needs the duplicate handling from step five to be solid.
Step 7: Do the logs tell you what happened?
Open a log file after a test run. For each alert you should be able to find: when it arrived, what was parsed from it, which account it targeted, and the broker's return code or the reason it was rejected before reaching the broker. If the log only says "received" and "sent", you cannot diagnose a missing trade later. If it prints the full raw request, go back to step two.
Step 8: What survives a restart?
Stop the process while an alert is mid-flight on a demo account, then start it again. Does the project persist anything, or does it start empty? Neither answer is wrong, but the project should say which it is, and you should know that an instruction received but not yet placed is either replayed or lost. This is the hardest thing to see by reading; it is the reason the follow-up article puts a restart test on a demo account rather than trusting the code review alone.
Step 9: Who maintains it?
TradingView changes its alert behaviour, MetaQuotes updates the terminal, brokers rename servers. The last question is not about code: whose job is it to notice and fix? Anthropic's guidance for its own coding tool makes the general point for any generated code: "If you can't verify it, don't ship it"[7], and it recommends giving the assistant "a check it can run: tests, a build"[7]. Ask the assistant for tests alongside the code, then ask yourself who will run them in six months.
The review checklist
| Check | Open | Pass looks like | Fail looks like |
|---|---|---|---|
| 1. Dependencies | requirements / imports, README | Pinned versions; Windows + terminal stated | Unpinned; platform assumed |
| 2. Secrets | Search "password", "token" | Env vars; identifier in webhook, not password | Password in message, source or log |
| 3. Broker result | Line after send call | Return code compared; rejection logged | "OK" returned regardless |
| 4. Targeting | Symbol / account / volume handling | Allow-list, ceiling, explicit account | Pass-through of alert text |
| 5. Repeat delivery | Handler entry | Repeat within window recognised | Nothing; relies on never erroring |
| 6. Timing | Handler order of operations | Acknowledges within 3 s | Waits for fill inside request |
| 7. Logs | Log after a test | Arrival, parse, target, result code | "received / sent" only |
| 8. Restart | Startup code; demo test | Documented persist-or-drop | Unknown |
| 9. Owner | README, your calendar | Named person, test suite exists | Nobody |
The same nine checks for software you cannot read
If you use a commercial connector, you cannot open its source, so each check becomes a question. Here is where PineConnector's own material answers, and where it does not.
- Dependencies and platform: documented. The self-hosted route runs an EA inside MT5 on Windows; the hosted route, PineConnector Edge, runs the terminal on PineConnector's infrastructure and, per the Edge Guide, "Edge does not support custom or other third-party EAs"[8].
-
Secrets: the alert carries a licence ID, not a password, in the documented format
LicenseID,command,symbol,vol_lots=X[5]. Broker credentials on Edge are entered in the portal; the product page states they are encrypted in transit and at rest[9]. Who can view them and how they are revoked beyond changing your broker password is not documented; ask support. - Broker result and logs: the portal Signals Log records "when our server received the signal and when the PineConnector EA processed it"[5]. On Edge, the Guide states that "the Experts and Journal logs are not yet available"[8], so the broker's return code per instruction is visible on a self-hosted terminal and not yet in the hosted view.
- Targeting: the symbol-format warning above is PineConnector's own; the responsibility to use the broker's symbol name stays with you.
- Repeat delivery: not documented. Whether PineConnector recognises a TradingView resubmission of the same trigger is a question to put to support before relying on it. This article does not claim either way.
- Timing: not documented in the pages cited here; ask.
- Restart: the Edge Guide describes "controls for manually restarting or terminating your Edge MT5 instance"[8]. What happens to an instruction in flight during a restart is not documented; ask.
- Owner: for the hosted terminal, PineConnector; for your alerts, symbols and strategy, you. The product page's phrase is "managed infrastructure, not managed execution"[9].
Read that list the same way you would read your own project's review: a mix of documented answers and open questions. The open questions are the ones to send to support, for any vendor, before a live account is involved. If the answers point you toward not running a terminal yourself, the build-or-buy comparison lays out what changes hands and what does not.
Frequently asked questions
Can I skip the review if the assistant wrote tests?
No. Tests written by the same assistant test what it thought of. The checklist above covers the cases a generator tends to miss: repeat delivery, rejected orders, restarts and wrong targets.
Is Python or an MQL5 Expert Advisor the safer choice for a generated bridge?
Neither is safer by itself. The Python package requires a running terminal on the same Windows machine[1]; an EA runs inside the terminal and stops when it stops. Both need the same nine checks.
Should I run the review on a live account to see real behaviour?
No. Every check here can be done by reading and then confirmed on a demo account. The Edge Guide's advice for its own product applies generally: "We recommend using a demo account for your first setup and test trade"[8].
What is the single most important check?
Step three. A bridge that does not read the broker's return code will tell you it succeeded on the days it did not.
Next step: run the demo-account tests in Your AI-built bridge placed one trade. Nine tests to run next. If you decide not to operate a terminal yourself, the setup guide covers both the self-hosted and the hosted route.
Reviewed 10 September 2026. Facts and quotations were checked against the linked sources on that date.
Sources
- MetaQuotes – MQL5 Reference: MetaTrader module for integration with Python, accessed 10 September 2026.
- TradingView – How to configure webhook alerts, accessed 10 September 2026.
- MetaQuotes – order_check, accessed 10 September 2026.
- MetaQuotes – order_send, accessed 10 September 2026.
- PineConnector Docs – Test Alert, accessed 10 September 2026.
- TradingView – Webhook resubmission, accessed 10 September 2026.
- Anthropic – Best practices for Claude Code, accessed 10 September 2026.
- PineConnector Docs – Edge (Early Access), accessed 10 September 2026.
- PineConnector – PineConnector Edge: managed MT5 hosting, accessed 10 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.
