Webhook to MT5 — execute JSON signals from any system

Risk warning: CFDs are complex instruments with a high risk of losing money rapidly due to leverage. 70–80% of retail investor accounts lose money when trading CFDs. Risk disclosure · Past performance.

The endpoint is source-agnostic: anything that can issue an HTTPS POST can trade — 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 a free PipSync account

   Sign up at app.pipsync.io — no credit card needed. Everything this integration requires, including the webhook source and the test-signal tool, is available on the free plan, so you can develop against the endpoint before paying anything.

2. 2

   Connect your MT5 account

   Add a broker account in the dashboard and select MetaTrader 5. Start with a demo account so you can iterate on your sender without real money at stake.

3. 3

   Create a webhook source and copy your URL

   Add a webhook source under Sources. PipSync generates a unique URL containing a secret token — 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: action and symbol are required; price, sl, tp, lots and comment are optional. 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), symbol filters and a max-open-trades cap; these run server-side on every payload. Note that a lots field in the payload overrides the configured sizing for that one trade — omit it from your sender unless you want that behaviour. You can also enable manual approval to inspect each trade before it executes.

6. 6

   Send a test signal and go live

   Use the test-signal feature on your webhook source to see exactly how the payload was parsed and whether the broker accepted the order. Keep the route on demo until several real payloads execute exactly as you expect.

Typical setup time: about 12 minutes.

A minimal order is a flat JSON object with an action, a symbol and optional protective levels: { "action": "buy", "symbol": "EURUSD", "sl": 1.0800, "tp": 1.0950 }. The action field accepts "buy", "sell" or "close"; symbol must match the instrument name in your broker's MT5 symbol list; sl and tp are absolute price levels and can be set to 0 to omit them.

Three more fields give you finer control: price sets a specific entry (0 means execute at market), lots overrides your configured lot sizing for that one trade (omit it to let your server-side risk rules size the position), and comment attaches a free-text trade comment. Because "close" closes the open position on the given symbol, a strategy can manage its entire trade lifecycle — open, protect, exit — through the same endpoint.

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 immediately if it is ever exposed — anyone holding the URL can submit signals to your account. Your server-side risk rules, symbol filters and optional manual-approval mode still stand between an unexpected request and your MT5 account, 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 trade. Risk checks such as position sizing, symbol filters and max open trades 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. The symbol field must match the instrument name exactly as it appears in your broker's MT5 symbol list, and brokers routinely use their own variants of standard names — verify against the broker's symbol list and confirm with a test signal before trusting an automated mapping.

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, respect the inbound webhook rate limit for your plan — it is counted per minute, separately from the read API, and scales by tier. On a 429 response, read the Retry-After header and back off with jitter instead of hammering the endpoint.