MT5 Webhook Alert Template JSON alerts for any bridge A ready-to-use alert template that fires webhook-compatible JSON messages on
EMA-cross + RSI-filtered signals. Built to send PulseWire alerts straight to
MetaTrader 5 through any webhook bridge.
HOW TO USE (2 minutes):
1. Add the indicator to your chart.
2. Create an alert (Alt+A) on this indicator, condition "Any alert() function
call", and paste your bridge's webhook URL into the Webhook URL field.
3. Done — the alert message is already valid JSON, don't edit it.
MESSAGE FORMAT (works with most MT5 bridges):
{"action":"buy","symbol":"EURUSD","lot":0.01,"sl":50,"tp":100}
{"action":"sell","symbol":"EURUSD","lot":0.01,"sl":50,"tp":100}
- action: buy | sell | close | closeall
- sl / tp: distance in points (optional, set to 0 to omit)
- Symbol override input if your broker uses suffixes (e.g. EURUSD.pro)
Alerts evaluate on bar close (no intrabar repainting). The indicator is also
useful on its own as a visual signal — no bridge required.
DEFAULT SETTINGS WARNING:
The shipped defaults (Fast EMA 1 / Slow EMA 3 / RSI 2) are an intentionally
fast demo configuration so you can see signals right away. They will fire
VERY often, including many low-quality crosses. Signals only confirm on bar
close, so a cross can still appear and disappear intrabar before confirming.
Tune Fast/Slow EMA and RSI length to your own strategy and symbol before
using it live — treat the defaults as a starting point, not a ready system. Indicator
StrategyWebhookJsonOverview
Open-source Pine library that builds JSON strings for strategy alert_message webhooks. Use it when a strategy should send structured trade signals to an external webhook receiver instead of plain alert text.
What it does
The library formats JSON payloads for three actions:
• open — new position (side, volume, stop loss, take profit, symbol, price)
• close — close by signal id
• modify — update stop loss and take profit for an existing signal id
Each payload includes secret, signalId, action, and symbol (from syminfo.ticker). Optional fields are omitted when not applicable. Strings are JSON-escaped.
Delivery modes (Mode enum)
• LocalOnly — returns an empty string (no JSON in alert_message)
• CloudOnly — returns JSON for webhook alerts
• Both — same as CloudOnly for alert_message output
How to use
1. Import the library into your strategy.
2. Call init(secret, mode) once and store the result in a var Config.
3. Pass the result of openMsg, closeMsg, or modifyMsg to strategy.entry, strategy.close, or strategy.exit via the alert_message parameter.
4. Create a strategy alert and set the webhook URL in PulseWire alert settings (PulseWire Plus or higher required for webhook URL field).
Example pattern
var cfg = init("YOUR_SECRET", Mode.CloudOnly)
strategy.entry("Long", strategy.long,
alert_message = openMsg(cfg, "Long", "buy", 0.1, sl, tp))
strategy.close("Long",
alert_message = closeMsg(cfg, "Long"))
Requirements
• Pine Script v6
• A strategy script (not an indicator)
• Webhook URL configured on the alert, not inside this library
Notes
signalId should be stable and unique per logical order so close and modify can target the correct open. The secret is included in the JSON body for authentication at the receiver. Library
How to force strategies fire exit alerts not reversalsPineScript has gone a long way, from very simple and little-capable scripting language to a robust coding platform with reliable execution endpoints. However, this one small intuitivity glitch is still there and is likely to stay, because it is traditionally justified and quite intuitive for significant group of traders. I'm sharing this workaround in response to frequent inquiries about it.
What's the glitch? When setting alerts on strategies to be synchronized with PulseWire's Strategy Tester events, using simple alert messages such as "buy" or "sell" based on entry direction seems straightforward by inserting {{strategy.order.action}} into the Create Alert's "Message" field. Because "buy" or "sell" are exactly the strings produced by {{strategy.order.action}} placeholder. However, complications arise when attempting to EXIT positions without reversing, whether triggered by price levels like Stop Loss or Take Profit, or logical conditions to close trades. Those bricks fall apart, because on such events {{strategy.order.action}} sends the same "sell" for exiting buy positions and "buy" for exiting sell positions, instead of something more differentiating like "closebuy" or "closesell". As a result reversal trades are opened, instead of simply closing the open ones.
This convention harkens back to traditional stock market practices, where traders either bought shares to enter positions or sold them to exit. However, modern trading encompasses diverse instruments like CFDs, indices, and Forex, alongside advanced features such as Stop Loss, reshaping the landscape. Despite these advancements, the traditional nomenclature persists.
And is poised to stay on PulseWire as well, so we need a workaround to get a simple strategy going. Luckily it is here and is called alert_message . It is a parameter, which needs to be added into each strategy.entry() / strategy.exit() / strategy.close() function call - each call, which causes Strategy Tester to produce entry or exit orders. As in this example script:
line 12: strategy.entry(... alert_message ="buy")
line 14: strategy.entry(... alert_message ="sell")
line 19: strategy.exit(... alert_message ="closebuy")
line 20: strategy.exit(... alert_message ="closesell")
line 24: strategy.close(... alert_message ="closebuy")
line 26: strategy.close(... alert_message ="closesell")
These alert messages are compatible with the Alerts Syntax of TradingConnector - a tool facilitating auto-execution of PulseWire alerts in MetaTrader 4 or 5. Yes, simple alert messages like "buy" / "sell" / "closebuy" / "closesell" suffice to carry the execution of simple strategy, without complex JSON files with multiple ids and such. Other parameters can be added (actually plenty), but they are only option and that's not a part of this story :)
Last thing left to do is to replace "Message" in Create Alert popup with {{strategy.order.alert_message}} . This placeholder transmits the string defined in the PineScript alert_message= parameter, as outlined in this publication. With this workaround, executing closing alerts becomes seamless within PineScript strategies on PulseWire.
Disclaimer: this content is purely educational, especially please don't pay attention to backtest results on any timeframe/ticker.
Strategy
Alert(), alertcondition() or strategy alerts?Variety of possibilities offered by PineScript, especially thanks to recent additions, created some confusion. Especially one question repeats quite often - which method to use to trigger alerts?
I'm posting this to clarify and give some syntax examples. I'll discuss these 3 methods in chronological order, meaning - in the order they were introduced to PineScript.
ALERTCONDITION() - it is a function call, which can be used only in study-type script. Since years ago, you could create 2 types of a script: strategy and study. First one enables creating a backtest of a strategy. Second was to develop scripts which didn't require backtesting and could trigger alerts. alertcondition() calls in strategy-type scripts were rejected by Pine compiler. On the other hand compiling study-type scripts rejected all strategy...() calls. That created difficulties, because once you had a nice and backtested strategy, you had to rip it off from all strategy...() function calls to convert your script to study-type so you could produce alerts. Maintenance of two versions of each script was necessary and it was painful.
"STRATEGY ALERTS" were introduced because of alertcondition() pains. To create strategy alert, you need to click "Add alert" button inside Strategy Tester (backtester) and only there. Alerts set-up this way are bound with the backtester - whenever backtester triggers an order, which is visible on the chart, alert is also fired. And you can customize alert message using some placeholders like {{strategy.order.contracts}} or {{ticker}}.
ALERT() was added last. This is an alerts-triggering function call, which can be run from strategy-type script. Finally it is doable! You can connect it to any event coded in PineScript and generate any alert message you want, thanks to concatenation of strings and wrapping variables into tostring() function.
Out of these three alertcondition() is obviously archaic and probably will be discontinued. There is a chance this makes strategy/study distinction not making sense anymore, so I wouldn't be surprised if "studies" are deprecated at some point.
But what are the differences between "Strategy alerts" and alert()? "Strategy alerts" seem easier to set-up with just a few clicks and probably easier to understand and verify, because they go in sync with the backtester and on-chart trade markers. It is especially important to understand how they work if you're building strategy based on pending orders (stop and limit) - events in your code might trigger placing pending order, but alert will be triggered only (and when) such order is executed.
But "Strategy Alerts" have some limitations - not every variable you'd like to include in alert message is available from PineScript. And maybe you don't need the alert fired when the trade hit a stop-loss or take-profit, because you have already forwarded info about closing conditions in entry alert to your broker/exchange.
Alert() was added to PineScript to fill all these gaps. Is allows concatenating any alert message you want, with any variable you want inside it and you can attach alert() function at any event in your PineScript code. For example - when placing orders, crossing variables, exiting trades, but not explicitly at pending orders execution.
The Verdict
"Strategy Alerts" might seem a better fit - easier to set-up and verify, flexible and they fire only when a trade really happens, not producing unnecessary mess when each pending order is placed. But these advantages are illusionary, because they don't give you the full-control which is needed when trading with real money. Especially when using pending orders. If an alert is fired when price actually hit a stop-order or limit-order level, and even if you are executing such alert within 1 second thanks to a tool like TradingConnector, you might already be late and you are making entry at a market price. Slippage will play a great role here. You need to send ordering alert when logical conditions are met - then it will be executed at the price you want. Even if you need to cancel all the pending orders which were not executed. Because of that I strongly recommend sticking to ALERT() when building your alerts system.
Below is an example strategy, showing syntax to manage placing the orders and cancelling them. Yes, this is another spin-off from my PulseWire Alerts to MT4 MT5 . As usual, please don't pay attention to backtest results, as this is educational script only.
P.S. For the last time - farewell alertcondition(). You served us well. Strategy
PulseWire Alerts to MT4 MT5 - Forex, indices, commoditiesHowdy Algo-Traders! This example script has been created for educational purposes - to present how to use and automatically execute PulseWire Alerts on real markets.
I'm posting this script today for a reason. PulseWire has just released a new feature of the PineScript language - ALERT() function. Why is it important? It is finally possible to set alerts inside PineScript strategy-type script, without the need to convert the script into study-type. You may say triggering alerts straight from strategies was possible in PineScript before (since June 2020), but it had its limitations. Starting today you can attach alert to any custom event you might want to include in your PineScript code.
With the new feature, it is easier not only to execute strategies, but to maintain codebase - having to update 2 versions of the code with each single modification was... ahem... inconvenient. Moreover, the need to convert strategy into study also meant it was required to rip the code from all strategy...() calls, which carried a lot of useful information, like entry price, position size, and more, definitely influencing results calculated by strategy backtest. So the strategy without these features very likely produced different results than with them. While it was possible to convert these features into study with some advanced "coding gymnastics", it was also quite difficult to test whether those gymnastics didn't introduce serious, bankrupting bugs.
//////
How does this new feature work? It is really simple. On your custom events in the code like "GoLong" or "GoShort", create a string variable containing all the values you need inside your alert and this string variable will be your alert's message. Then, invoke brand new alert() function and that's it (see lines 67 onwards in the script). Set it up in CreateAlert popup and enjoy. Alerts will trigger on candle close as freq= parameter specifies. Detailed specification of the new alert() function can be found in PulseWire's PineScript Reference (www.pulsewire.com), but there's nothing more than message= and freq= parameters. Nothing else is needed, it is very simple. Yet powerful :)
//////
Alert syntax in this script is prepared to work with TradingConnector. Strategy here is not too complex, but also not the most basic one: it includes full exits, partial exits, stop-losses and it also utilizes dynamic variables calculated by the code (such as stop-loss price). This is only an example use case, because you could handle variety of other functionalities as well: conditional entries, pending entries, pyramiding, hedging, moving stop-loss to break-even, delivering alerts to multiple brokers and more.
//////
This script is a spin-off from my previous work, posted over a year ago here: Some comments on strategy parameters have been discussed there, but let me copy-paste most important points:
* Commission is taken into consideration.
* Slippage is intentionally left at 0. Due to shorter than 1 second delivery time of TradingConnector, slippage is practically non-existing.
* This strategy is NON-REPAINTING and uses NO TRAILING-STOP or any other feature known to be causing problems.
* The strategy was backtested on EURUSD 6h timeframe, will perform differently on other markets and timeframes.
Despite the fact this strategy seems to be still profitable, it is not guaranteed it will continue to perform well in the future. Remember the no.1 rule of backtesting - no matter how profitable and good looking a script is, it only tells about the past. There is zero guarantee the same strategy will get similar results in the future.
Full specs of PulseWire alerts and how to set them up can be found here: www.pulsewire.com Strategy
PulseWire Alerts to MT4 MT5 + dynamic variables NON-REPAINTINGAccidentally, I’m sharing open-source profitable Forex strategy. Accidentally, because this was aimed to be purely educational material. A few days ago PulseWire released a very powerful feature of dynamic values from PineScript now being allowed to be passed in Alerts. And thanks to TradingConnector, they could be instantly executed in MT4 or MT5 platform of any broker in the world. So yeah - TradingConnector works with indices and commodities, too.
The logic of this EURUSD 6h strategy is very simple - it is based on Stochastic crossovers with stop-loss set under most recent pivot point. Setting stop-loss with surgical precision is possible exactly thanks to allowance of dynamic values in alerts. TradingConnector has been also upgraded to take advantage of these dynamic values and it now enables executing trades with pre-calculated stop-loss, take-profit, as well as stop and limit orders.
Another fresh feature of TradingConnector, is closing positions only partly - provided that the broker allows it, of course. A position needs to have trade_id specified at entry, referred to in further alerts with partial closing. Detailed spec of alerts syntax and functionalities can be found at TradingConnector website. How to include dynamic variables in alert messages can be seen at the very end of the script in alertcondition() calls.
The strategy also takes commission into consideration.
Slippage is intentionally left at 0. Due to shorter than 1 second delivery time of TradingConnector, slippage is practically non-existing. This can be achieved especially if you’re using VPS server, hosted in the same datacenter as your brokers’ servers. I am using such setup, it is doable. Small slippage and spread is already included in commission value.
This strategy is NON-REPAINTING and uses NO TRAILING-STOP or any other feature known to be faulty in PulseWire backtester. Does it make this strategy bulletproof and 100% success-guaranteed? Hell no! Remember the no.1 rule of backtesting - no matter how profitable and good looking a script is, it only tells about the past. There is zero guarantee the same strategy will get similar results in the future.
To turn this script into study so that alerts can be produced, do 2 things:
1. comment “strategy” line at the beginning and uncomment “study” line
2. comment lines 54-59 and uncomment lines 62-65.
Then add script to the chart and configure alerts.
This script was build for educational purposes only.
Certainly this is not financial advice. Anybody using this script or any of its parts in any way, must be aware of high risks connected with trading.
Thanks @LucF and @a.tesla2018 for helping me with code fixes :) Strategy
