Order Fills Only vs alert() Function Calls: Setup Guide

The order fills only vs alert() function calls choice depends on which event should send your order and where its message is built. Use Order fills only when automation follows a TradingView strategy’s simulated fills and the configured fill message supplies the required payload. Use alert() function calls only when the script deliberately builds and sends compatible order messages through alert().

Neither choice proves that a live broker order filled. TradingView generates an event, the webhook carries its message, PickMyTrade processes it, and the broker handles the resulting order. This guide explains how to select the right event source for pickmytrade.io and verify entries, exits and reversals before going live.

Key takeaways

• Order-fill alerts follow simulated strategy fills, not broker confirmations.
• alert() events follow the script’s executed calls and frequency rules.
• The event source and message format must match the receiving workflow.
• Selecting both can duplicate instructions if both streams describe the same trade.
• Verify the complete exit route, not only the entry.

What do the three strategy alert options mean?

TradingView strategies can generate order-fill events and, when their code includes alert() calls, custom script events. The alert condition determines which events are included. TradingView’s alert() setup guide describes fills only, calls only, and the combined option.

Order fills only sends notifications when TradingView’s broker emulator fills strategy orders. That includes eligible entry and exit fills unless an order’s alerts have been deliberately disabled. The message can use a common fill template or custom order messages configured by the script.

alert() function calls only sends the messages supplied to executed alert() calls. A plotted buy marker or a strategy order does not automatically create such a call. The script must contain the intended notification logic, and its frequency and execution rules must allow the call to trigger.

The combined option includes both event sources. It is appropriate only when you intentionally designed and tested both streams. It is not a general fix for missing trades or exits.

Order fills only vs alert() function calls: how should you choose?

Start with how the script sends trade instructions: what event sends an entry, what message it sends, and how it later exits. Match that design to PickMyTrade’s generated payload and the broker-specific workflow. Do not choose by whether one option makes a Message field appear.

For a conventional strategy workflow that follows simulated orders, use the order-fill event source with the correct generated strategy message. This commonly means Order fills only. Confirm the payload for the actual pickmytrade.io connection rather than copying a template intended for Tradovate on pickmytrade.trade.

For a script that constructs complete compatible messages inside alert(), select the calls-only route described by its author. Merely selecting calls only does not convert the script’s text into a PickMyTrade order. The author’s message must contain the required action, instrument, quantity, account routing and other fields for that workflow.

Indicators do not have strategy order-fill events. They may expose named alertcondition() conditions or Any alert() function call. PickMyTrade’s Tradier setup guide distinguishes INDICATOR and STRATEGY modes; choose the mode and condition that match the actual script and receiving route.

Match the trigger to your pickmytrade.io setup

Generate the configuration for your actual broker connection, then verify the items below. Do not assume a vendor’s alert text or another connector’s JSON can be used unchanged. The receiving mode must match the intended message semantics, not simply the script’s label.

• Connection and account: confirm broker, account, demo/live environment and execution symbol.
• Trigger: identify the fill event, custom call or named indicator condition that supplies the instruction.
• Message: compare the actual outgoing payload with the generated configuration, including action, quantity and routing.
• Exits: select the documented exit mode and verify who sends each close or holds its protection.
• Destination: use the webhook URL supplied for that route and inspect one controlled demo event before proceeding.

Where does the outgoing message come from?

The message source changes with the trigger. For order-fill alerts, the alert’s fill-message template can contain supported strategy placeholders. For alert() events, the script supplies the string. Editing an unrelated message field does not necessarily change an alert() payload.

TradingView’s alert FAQ explains that alert() messages are dynamic strings and do not process placeholders. Putting {{strategy.order.action}} directly inside such a string does not make it resolve automatically. The developer must build the required values in code or through supported script inputs.

A vendor script may offer webhook inputs for this purpose. Ask the author which version and alert condition they support, and request examples of the actual entry, full-exit, partial-exit and reversal messages. Compare those with the generated PickMyTrade configuration before enabling execution.

What does strategy.order.alert_message do?

The {{strategy.order.alert_message}} placeholder inserts the custom alert_message supplied by the strategy order command responsible for the fill. It is a message-routing mechanism for order-fill alerts, not a substitute for alert() calls or a live broker receipt.

When the fill template contains only this placeholder, every order intended to send an executable message needs the appropriate custom message. TradingView’s alerts documentation describes empty replacement text when a relevant order lacks alert_message. Check entries and exits, including stop and target paths.

Also inspect disable_alert settings on order commands. Suppression may be deliberate when another route manages an exit. Removing it without understanding that design can introduce a second close instruction. Verify the complete flow before changing the code.

Despite the similar names, alert_message is an argument that customizes an order’s fill notification, while alert() is a function that creates a separate script event. Adding alert_message to an order does not create an alert() call. Selecting calls only therefore excludes the fill notification carrying that custom text.

When do the alerts actually fire?

A fill alert follows the broker emulator’s fill event. An alert() event follows script execution and its configured frequency. These can occur at different times even if they relate to the same trading idea. Neither should be treated as a guaranteed live fill at the chart price.

Under typical default strategy behavior, calculations occur at bar close and a newly created market order fills on the next available tick. Settings such as process_orders_on_close, calc_on_every_tick and calc_on_order_fills can alter the sequence. Pending simulated orders also have their own fill conditions. See TradingView’s strategy documentation.

For example, a strategy may call alert() when it decides to enter, then produce an order-fill event later. A live market order sent from the first event and a live order sent from the second are two submissions, even though the chart may display one trading idea. This is a hypothetical explanation, not a measured latency result.

Strategy alert() calls normally execute at bar close under default calculation settings. alert.freq_all allows eligible calls on script executions; it does not by itself make the strategy calculate on every tick. Indicator execution differs, and order-fill notifications follow fill events. Change calculation settings only with an understanding of the script’s intended real-time behavior.

Why can selecting both create duplicate trades?

If alert() sends a buy instruction and the strategy fill event sends another buy instruction for the same entry, the combined setting can deliver both. The receiver’s position rules may affect the outcome, but those rules should not replace diagnosing the duplicate source.

Two separate active alerts can cause the same problem. Review alerts created before and after script changes, other strategies on the same instrument, account-routing lists, quantity multipliers and copier routes. A transaction larger than expected can also come from reversal sizing rather than duplicate notifications.

Keep one intended instruction source for each action unless a tested design requires more. For separate informational notices, use a separate destination rather than assuming the trade receiver will ignore arbitrary text. Do not enable both event sources just to make an entry or exit appear.

Hypothetical sequence: the script executes an alert() call containing a buy instruction for one unit, then its simulated entry fills and the fill template sends another buy instruction for one unit. With both sources enabled, two trade instructions may reach the receiver. The final position depends on routing and position rules; verify the messages before changing quantities.

Why might entries arrive but exits go missing?

The entry path and exit path may use different mechanisms. A script can call alert() for entry but use strategy.exit() for a simulated stop. With calls only selected, the fill event is excluded unless the script separately creates the required exit notification.

An alert() call placed at the decision to create an order is not a fill callback. A script can inspect strategy state on later calculations, but that is a different mechanism and can have different timing. Do not assume a custom exit alert will occur at the simulated stop’s price or moment.

For a fills-only route, inspect the exit message, any suppressed alerts and the receiving exit configuration. For either route, check that the alert is active, the webhook is delivered, the message is accepted and the broker processes the instruction.

Who should manage the exit?

Assign a clear exit route and understand what happens if a second close instruction arrives. A strategy-controlled exit depends on its intended alert reaching the automation route; a broker-held stop or target depends on the corresponding order being accepted and remaining active.

PickMyTrade’s TradeLocker strategy guide distinguishes strategy-controlled exits, attached SL/TP and multiple exits. These are examples of a broker-specific setup, not proof that every connector offers identical exit behavior. Follow the current guide for your selected broker.

After an entry, inspect the broker’s positions and protective orders. If both a broker exit and a later strategy close can act, test the outcome with support-approved configuration. Avoid broadly disabling exit alerts without ensuring another valid management path exists.

How should you test the configuration?

Use an authorized demo or paper environment supported by your broker route. Define the expected message count, action, quantity and final position before each test. A backtest alone cannot validate webhook delivery or broker handling.

1. Test an entry from flat and compare TradingView history, PickMyTrade logs and broker orders.
2. Test the actual stop, target or signal exit your workflow uses. Inspect the non-empty message or accepted broker protection, as applicable.
3. Test partial exits if used, checking the remaining position and protective quantities.
4. Test a reversal if used, checking the transaction size and final direction. A reversal transaction can include quantity needed to offset an existing position.
5. Replace a changed alert deliberately and ensure a superseded source is not still running.
6. If both event types are intentionally used, verify each event and message separately before testing their interaction.

Preserve the exact trigger, script version, inputs, account, symbol, generated message and timestamps. Remove credentials from records shared with support. If a request’s result is uncertain, inspect broker orders and positions before resending it.

Frequently asked questions

Choose the event source, then verify the trade

The correct selection is the one that sends exactly the intended compatible instruction at the intended event. Check where the message is built, how every exit is generated, and which broker-specific PickMyTrade mode receives it.

Start with the pickmytrade.io documentation for your broker and run entry, exit and reversal checks in demo. Keep the received message and final broker position as evidence that the route works as intended.

Disclaimer:
This content is for informational purposes only and does not constitute financial, investment, or trading advice. Trading and investing in financial markets involve risk, and it is possible to lose some or all of your capital. Always perform your own research and consult with a licensed financial advisor before making any trading decisions. The mention of any proprietary trading firms, brokers, does not constitute an endorsement or partnership. Ensure you understand all terms, conditions, and compliance requirements of the firms and platforms you use.

Also Checkout: Futures Position Sizing: Ticks, Points and Planned Risk