My first Python script connected to MT5 in eleven minutes. I remember because I timed it — pip install MetaTrader5, five lines of code, and there were live EURUSD ticks flowing into my terminal like I had performed actual magic. Forty minutes later that same script doubled a losing position during a news spike because I never checked the order return code, and I watched a −$180 loss become −$430 while the script cheerfully reported success. The connection was never the hard part of mt5 api python integration. The hard part is everything you assume the eleven-minute tutorial already handled.
Two years later, Python runs my journaling, my signal logging, and my risk checks — but not my entries. That boundary exists because of the bugs below. This guide covers the full integration: what the bridge is good for, the lot-size math your script must compute, the mistakes that traded real money, and the latency tests I ran before trusting any of it.
What the Python Bridge Is Actually Good For
The MetaTrader5 Python package is a bridge, not a trading platform. It lets a Python script talk to a running MT5 terminal on the same machine: pull ticks and bars, read account info and open positions, and send trade requests. What it does not do is run standalone — no terminal, no bridge. Every architecture decision flows from that constraint.
Here is how I divide the labor after two years of mistakes. Python handles analysis and bookkeeping: downloading M1 data for research, computing indicators with pandas instead of MQL5, logging every fill to a database, running the Monte Carlo reshuffles I described in my backtesting work. MT5 — the terminal, EAs, or manual trading — handles execution. The one exception is a kill-switch script: a tiny Python program that closes all positions if equity drops below a line. It has one job, 40 lines, and it has saved me exactly once, which is exactly enough.
The reason for the boundary is failure modes. A Python script that crashes mid-loop leaves orders unmanaged; an EA lives inside the terminal's event system and dies with it. When my journaling script hit a network hiccup in March 2025, it just stopped logging — annoying but harmless. If that had been an entry script, "harmless" would have been a different word. Keep Python away from anything where a crash costs money, and it becomes the best tool in your stack. The API trading connectivity guide covers the broker-side reliability half of this equation.
Wiring the Signal Calculator Into Your Script Logic
Before any script of mine computes a position size, I validate the math against the DarkWolf MT5 Signal Calculator by hand — once. The calculator is the reference implementation; the script is the automation. If they disagree, the script is wrong. Here are the inputs your sizing function needs, mapped to the calculator's fields:
| Input Field | What it means | Sample value |
|---|---|---|
| Account Balance | From mt5.account_info().balance — live, not hardcoded | 25,000 |
| Risk % | Config constant, never derived from market data | 1 |
| Stop (points) | Strategy stop in MT5 points, not pips — convert explicitly | 350 |
| Symbol Specs | From mt5.symbol_info(): tick_value, tick_size, volume_min/max/step | EURUSD specs |
The connection boilerplate is genuinely five lines — this is the entire "eleven minutes" part:
import MetaTrader5 as mt5
if not mt5.initialize():
raise SystemExit("terminal not running")
print(mt5.account_info().balance) # proves the bridge is live
print(mt5.symbol_info("EURUSD").tick_value) # proves specs are readable
If initialize() fails, the terminal is not running or not logged in — the two causes cover 95% of "my script broke" support threads. Python's official site for the language itself, and MetaTrader 5's help pages document the terminal side of the integration.
The Lot-Size Math Your Script Must Get Right
This is the formula that separates scripts that work from scripts that blow up on JPY pairs and gold. MT5 thinks in points and tick values, not pips and dollars — your script must convert, every time, from live symbol specs:
| Variable | Meaning | Example value |
|---|---|---|
| Balance | Live account balance from the bridge | 25,000 |
| Stoppoints | Stop distance in MT5 points (350 points = 35 pips on 5-digit) | 350 |
| Tick Value / Tick Size | Value of one tick move per lot, from symbol specs | 1.0 / 0.00001 |
| Point | Smallest price change, from symbol specs | 0.00001 |
Run it: ($25,000 × 1% = $250) ÷ (350 × 1.0 ÷ 0.00001 × 0.00001) = 250 ÷ 350 = 0.71 lots. Then — and this is the step my first script skipped — round down to the broker's volume step and clamp to volume_min/volume_max from the symbol specs. A computed 0.71 on a broker with 0.1 step becomes 0.7. Skip the clamp and the order gets rejected; worse, skip the rounding and some brokers fill at a size you did not intend. Validate once against the calculator, then trust the script.
Bugs That Traded Real Money Before I Caught Them
Bug one: the unchecked return code. My first live script sent an order, assumed success, and looped. During a news spike the order was rejected (price requote), the script did not read result.retcode, and on the next loop iteration it sent the order again — into a market that had moved 40 pips. −$430 instead of −$180. Every order call must check the retcode and halt on anything but TRADE_RETCODE_DONE. This is not defensive programming. It is the minimum.
Bug two: the timezone massacre. I pulled H1 bars with copy_rates_from_pos, ran my analysis in local time, and generated signals shifted by the broker-server offset — three hours on my setup. The script was analyzing the "London open" candle that was actually the 5 AM dead zone. Two weeks of beautiful backtest-shaped signals, all phase-shifted. Now every script asserts the server timezone offset on startup and refuses to run if it changed — brokers move servers, and DST changes the offset twice a year.
Bug three: the silent data gap. A VPS reboot left the terminal disconnected for six hours; my data-pull script kept running, received empty frames, and forward-filled them as if nothing happened. The research built on that week had a six-hour hole wearing a full dataset's clothes. Now every pull validates bar counts against expected session hours and screams — logs, push alert, the works — on any gap. Connection monitoring on the broker side prevents this entire class of failure.
The Weekend I Automated My Entire Journal
The case study with a happy ending. In early 2026 I spent a weekend building the one Python project I recommend to every trader: an automatic trade journal. No entries, no exits, no money — just reading. The script polls open and closed positions every 60 seconds, logs every fill with timestamp, symbol, volume, price, and P&L to a local database, and generates a weekly summary: win rate, average R, max drawdown, and — the metric that changed my trading — profit by hour of day.
| Step | Action | Result |
|---|---|---|
| 1. Poll | history_deals_get() every 60 seconds on the VPS | Zero missed fills in 4 months |
| 2. Store | SQLite database, one row per deal, immutable | 412 deals logged |
| 3. Analyze | Weekly pandas summary: R multiples by session and hour | Asian session: −3.1R total |
| 4. Act | Stopped trading the Asian session entirely | Monthly expectancy up ~18% |
The human-value detail: I had felt like my Asian-session trades were fine — a few memorable winners will do that to a memory. The script did not have memories. It had 412 rows, and the rows said the session was a slow leak. Four months of automated journaling found an edge improvement that two years of manual journaling missed, because I always "forgot" to log the losers promptly. If you build exactly one Python project, build this one. The economic calendar integration guide is the natural next step — tagging each logged trade with the news context around it.
Three Scripts, Timed and Stress-Tested
Before trusting the bridge for anything recurring, I benchmarked the three operations every script depends on — 100 iterations each, on the London VPS, during the New York session:
| Operation | Python call | Median time | Worst of 100 |
|---|---|---|---|
| Tick snapshot | symbol_info_tick() | 3 ms | 41 ms |
| 1,000 M1 bars | copy_rates_from_pos() | 180 ms | 1.2 s |
| Market order round-trip | order_send() + retcode | 320 ms | 2.8 s (news) |
The takeaway for system design: reads are fast enough for anything — poll ticks every second without worry. Order round-trips are fine in normal conditions but stretch to nearly 3 seconds around news, which is why entry scripts must never assume instant fills and must always handle partial fills and requotes. My kill-switch script polls equity every 5 seconds; at 3 ms per read, the overhead is nothing. Design your polling intervals from measured numbers, not from hope.
MT5 Python Integration: Hard Questions
Do I need to know MQL5 to use the Python integration?
No — that is the entire appeal. The Python package talks to the terminal directly, so you never write a line of MQL5. You do need to understand MT5 concepts (points vs pips, tick value, order filling modes) because the bridge exposes the terminal's reality without translating it. I knew zero MQL5 when I started and was productive in a weekend; the bugs I hit were all conceptual, not language-related.
Can Python run EAs or replace the MT5 terminal?
No. The bridge requires a running, logged-in MT5 terminal on the same machine — it is a remote control, not a replacement. Your Python script cannot run on a machine without MT5 installed, and it cannot do anything the terminal itself cannot do. For 24/7 operation, that means a Windows VPS running the terminal with your script alongside it. There is no headless or Linux-native shortcut.
Is it safe to let a Python script place live trades?
It can be, but my bar is high after the −$430 news-spike incident. Minimum requirements: every order checks the retcode, every computed volume is clamped to broker min/max/step, a global kill-switch caps daily loss, and the script logs everything. Even then, I keep entries manual and let Python handle journaling, monitoring, and risk checks. A script that watches is an asset; a script that trades while you sleep is a liability with a keyboard.
Why does copy_rates return fewer bars than I asked for?
Usually one of three things: the symbol is not selected in Market Watch (call symbol_select() first), the requested history is not downloaded (open the chart once to force it), or you asked for more bars than exist on that timeframe. My data-pull functions now assert the returned count and retry after selecting the symbol — two lines that eliminated an entire category of silent research corruption.
How do I handle the broker timezone offset correctly?
Read it from the terminal, never hardcode it. Compare a known bar timestamp against UTC, compute the offset at startup, and abort if it differs from your expected value — brokers change servers and DST shifts the offset twice a year. All analysis should happen in server time or UTC, converted explicitly. My two weeks of phase-shifted signals came from assuming the offset was a constant. It is a variable wearing a constant's name tag.
What is the best VPS setup for running Python with MT5?
A Windows VPS near your broker’s server (London for most EU/UK brokers), 2+ CPU cores, 4 GB RAM — the terminal is the hungry one, not Python. Run the terminal and script as scheduled tasks that restart on reboot, log with rotation, and add an external heartbeat so you know within minutes if the box goes dark. Location beats specs.
Can I use the bridge for crypto on MT5?
Yes, if your broker offers crypto symbols on MT5 — the bridge does not care what the symbol is. But check the specs carefully: crypto symbols often have unusual tick values, wide volume steps, and weekend trading halts that break naive scripts. My sizing function reads everything from symbol_info() precisely because hardcoding forex assumptions onto BTCUSD is how you accidentally order 100 lots. The crypto on MT5 guide covers the symbol quirks in detail.