Webhook to MT5 — send JSON signals from any system

Risk warning: Trading CFDs and other leveraged products is complex and carries a high risk of losing money rapidly because of leverage. Industry data indicates that 70–80% of retail trading accounts lose money on these products. Risk disclosure · Past performance.

The endpoint is source-agnostic: anything that can issue an HTTPS POST can send a signal — a Python screener, a Node bot, a cron job, a no-code automation. There is no EA to install, no MQL5 to write and no VPS to keep online. The MT5 connection runs in PipSync's cloud, and signed outbound webhooks report executions back to your own system so you can close the loop programmatically.

1. 1

   Create your PipSync account and subscribe to a plan

   Sign up at app.pipsync.io (the $0 Free plan needs no card but only parses signals), then subscribe to a plan that includes webhook integration (payment method required, cancel any time). Everything this integration requires, including the webhook URL and the Recent alerts list, is included, so you can develop against the endpoint before you go live.

2. 2

   Connect your MT5 account

   Open Trading Accounts → Add account and select MetaTrader 5, using your master (trading) password. Start with a demo account so you can iterate on your sender without real money at stake.

3. 3

   Generate your webhook URL and copy it

   Go to Settings → Advanced → TradingView Alerts and click Generate webhook URL. PipSync generates a unique URL containing a secret token and shows it only once — that URL is your credential. Store it in an environment variable or secret manager, never in committed code.

4. 4

   Point your system at the endpoint

   From your bot, screener or script, send an HTTPS POST with the JSON payload: instrument, direction, entry, sl and tp1 are all required (prices above 0); other fields are ignored. Any HTTP client works — there is no SDK to install.

5. 5

   Set your server-side risk rules

   Configure position sizing (fixed lots or percent-risk), min/max lots and a max-open-positions cap; these apply when a signal is traded. A lots field in the payload is ignored. Every webhook signal waits on the Signals page for your review.

6. 6

   Send a test payload and go live

   Send one payload, then open Settings → Advanced → TradingView Alerts and check Recent alerts to see its status and, if it was rejected, the exact error. Keep the route on demo until several real payloads parse exactly as you expect.

Typical setup time: about 12 minutes.

A minimal signal is a flat JSON object with five required fields: { "instrument": "EURUSD", "direction": "buy", "entry": 1.0850, "sl": 1.0800, "tp1": 1.0950 }. direction accepts buy or sell (long and short also work); sl and tp1 are absolute price levels and must be above 0 — a payload with 0 is rejected.

Use tp1 to tp5 for several take-profit targets. Every other field, including lots and comment, is ignored: sizing always comes from your PipSync settings, and there is no close action. A valid payload becomes a signal for you to review; an invalid one gets an HTTP 422 with the reason listed under Recent alerts.

Each webhook source gets a unique HTTPS URL containing a secret token — the URL itself is the credential. That keeps the sender side deliberately simple: no OAuth flow, no request signing, no client library. curl, a five-line Python script or a serverless function can all authenticate the same way.

Treat the URL like a password. Keep it out of client-side code and public repositories, and regenerate it from the dashboard if you suspect a leak — anyone holding the URL can submit signals into your workspace and, if you have switched on TradingView auto-trade, trigger trades by sending it a TradingView alert. A request from any other system always waits for your review on the Signals page, but rotating a leaked URL should be the first response.

An EA-based bridge couples your automation to one running MT5 terminal — typically a Windows VPS you rent, patch and monitor, plus MQL5 code you maintain. If the terminal closes or the VPS reboots, your strategy is offline. PipSync moves the broker connection server-side through a cloud API bridge to MT5, so there is nothing installed in the terminal and nothing that dies with a desktop session.

It also decouples your language choice from MetaQuotes' ecosystem. Your screener can stay in Python, your execution logic in Rust or Node — if it can issue an HTTP POST, it can send a signal. Risk checks such as position sizing, min/max lots and max open positions run on PipSync's servers before any order is forwarded, so they apply consistently regardless of what sent the signal.

Subscribe your own endpoint to PipSync's outbound webhooks and you receive a signed JSON POST on events such as signal.received, trade.opened, trade.closed, trade.tp_hit and trade.sl_hit. Each delivery carries an X-PipSync-Signature header (a timestamp plus an HMAC-SHA256 digest) so you can verify authenticity before trusting the payload; reject anything whose timestamp is more than a few minutes old to block replays. Failed deliveries are retried up to 5 times with exponential backoff.

For polling and reconciliation there is also a REST read API — GET /v1/signals and GET /v1/trades — described by an OpenAPI 3.1 spec at /api/v1/openapi.json, so you can generate a typed client for your runtime. API keys for the read API are part of the Enterprise plan; the dashboard itself shows every parsed signal and resulting order on all plans.

Symbol naming is the most common integration bug. Brokers routinely use their own variants of standard names, and there is no symbol-mapping setting for webhooks — PipSync upper-cases the instrument and keeps only letters and digits. Check how it was read under Recent alerts and, if your broker spells it differently, message us in the support chat with the symbol and your broker.

PipSync's MT5 integration works with both hedging and netting account modes, handles partial fills, and places stop-loss and take-profit with the order so protection is held at the broker rather than in your script. If your sender can emit bursts, debounce on your side, and if you ever receive an HTTP 429, back off with jitter before retrying.