To automate an invite-only indicator, you need an accessible alert trigger or usable plot condition, a message compatible with the execution service, and clear rules for entries, exits and position size. Source-code access is not always required. A buy label on the chart, however, does not establish that the script exposes a usable automation event.
Table of Contents
- Key takeaways
- Can you automate an invite-only indicator without its source code?
- Which alert interface does the indicator provide?
- What must each entry and exit signal mean?
- Does the indicator provide usable stop-loss and take-profit values?
- How do you identify and verify a plot placeholder?
- Does a changing plot automatically move the broker stop?
- When does the signal become final?
- What should the author provide before you automate?
- How do you connect a compatible indicator to PickMyTrade?
- Worked example: a visible buy signal with a missing exit interface
- Worked example: a complete entry-time protection plan
- Is the indicator ready, or does it need changes?
- What should you test before enabling the workflow?
- Troubleshooting unresolved values and wrong events
- Frequently asked questions
- Automate the defined workflow, not just the chart marker
Before automating an invite-only indicator, check both its alert interface and your complete trading rules. You need to know what leaves TradingView and what the destination should do with it. In particular, decide whether an opposite event should exit, reduce, or reverse the existing position.
This guide explains what the indicator and the trading rules must provide before connecting to PickMyTrade. Here, “strategy” means your trading plan unless we explicitly say Pine strategy. Select the Indicator workflow for an indicator script; a paid or invite-only script is not automatically a Pine strategy.
Key takeaways
- Invite-only access protects code; it does not establish alert compatibility.
- Check separate alert conditions, script-generated messages, or usable plots.
- Define entries, exits, repeat signals and opposite signals before execution.
- Dynamic stops need accessible numeric values, not just drawn labels.
- Verify emitted messages and broker results in demo before relying on the route.
Can you automate an invite-only indicator without its source code?
Yes, when the script exposes the information needed by the supported automation route. TradingView’s publishing documentation explains that invite-only code is visible only to its author and use requires an invitation. That access model alone does not tell you which alerts, plots, or configurable messages the script provides.
Open Create Alert with the indicator added to the intended chart. Inspect the available conditions, inputs and author instructions. You are looking for an event with a defined meaning and a usable outgoing message. There is no need to recover hidden code when the author already exposes a suitable interface.
If the required outputs are absent, ask the author to add them. A separate helper can work with exposed plots where supported, but it cannot read arbitrary hidden variables or infer private logic from a label. Confirm the author’s usage terms and your account’s automation permissions before building around the script.
Which alert interface does the indicator provide?
Inspect whether the script offers separate conditions, script-generated alerts, or numeric plots usable in a chart alert. These interfaces differ in who controls the message and how direction is selected. Compatibility depends on the actual outgoing event, not simply on the presence of an Alerts button in TradingView.
| Interface | What to inspect | Automation implication |
|---|---|---|
| Separate conditions, such as Long and Short | Named choices from alertcondition(), plus an editable Message field | Configure the supported message for each event; keep direction-specific alerts distinct |
| Any alert() function call | Author’s message inputs, event filters and emitted text | The script supplies the runtime message; verify it can produce the required payload |
| Usable numeric plot | Available plot condition and its documented meaning | A chart alert can use an exposed series if it represents the intended signal |
| Only labels, drawings or dashboard text | Whether a matching alert or plot exists | Visual appearance alone does not supply an execution event |
TradingView’s alert FAQ distinguishes individually selectable alertcondition() triggers from “Any alert() function call.” With the latter, multiple executed calls can share one alert. Check the author’s event-selection controls so a long-only route does not also forward short, exit, or informational messages.
For alertcondition() alerts, users can edit the message when creating the alert. For alert() calls, the runtime text comes from the script. A hardcoded notification intended for Discord or a human reader may need author changes before it matches PickMyTrade’s connector format. Do not assume adding a webhook URL converts the message.
Plots provide another documented route. TradingView’s visuals documentation says plot-based chart alerts can exist without alert-specific Pine code. But the selected series and threshold must match the trading rule. A continuous trend line is not necessarily a one-time entry signal.
What must each entry and exit signal mean?
Write down the intended account outcome for every event before assigning a broker action. “Buy” can mean enter long from flat or add to an existing long. “Sell” can mean exit, reduce, or reverse. An indicator event needs a trading rule that resolves these differences for the supported route.
| Event | Question the trading plan must answer |
|---|---|
| Long entry | Enter only when flat, add to an existing long, or replace another position? |
| Short entry | Open short, close a long first, or ignore when already exposed? |
| Exit long | Close the whole relevant position or a supported partial quantity? |
| Exit short | Which destination and quantity should be closed? |
| Repeated same-side signal | Ignore, add, or reset the position? |
| Opposite signal | Close only, reverse, or require a separate exit? |
| Stop/target already filled | How should a later signal-driven exit be handled? |
These are design questions, not universal PickMyTrade behavior. Confirm the selected connector’s handling of repeats, reversals and closes. If the author supplies only entry signals, the workflow still needs a defined exit owner: broker-held protection, a supported integration rule, or a separate script event. Avoid two independent components managing exits without a clear plan.
Does the indicator provide usable stop-loss and take-profit values?
If stops and targets change with the indicator, the automation needs those numeric levels or a supported way to calculate them. A line or label drawn at a price does not necessarily expose a plot placeholder. Ask the author which output represents each level and when it is valid.
TradingView’s placeholder guide explains how plot values can appear in alert messages. Its plot placeholders refer to exposed outputs, not arbitrary private variables. Inspect the selected indicator and exact plot title, or use a verified plot index. Do not guess the output from its color or position.
| Value | Definition to obtain from the author |
|---|---|
| Entry reference | Signal close, intended limit price, or another reference |
| Stop loss | Absolute price or distance; unit and update timing |
| Take profit | Absolute price or distance; single target or multiple exits |
| Validity | Whether the output is numeric at the exact entry event |
| Later changes | Whether levels are fixed at entry or require separate update events |
A numeric value is not automatically a price. An RSI reading of 70 is an oscillator value, not a take-profit price for MNQ. Likewise, 10 can mean points, ticks or cash depending on the field. Map the author’s output to the connector’s documented units and verify the resulting order price.
Plot placeholders can access up to the first 20 plot series. If the author’s required output is unavailable through that interface, request an accessible output or a compatible script-generated message. The same visual line can have different technical implementations, so appearance cannot establish placeholder support.
How do you identify and verify a plot placeholder?
Start with the author’s documented numeric output, then check the selected indicator instance in TradingView. Use its plot titles and Data Window values where available to identify the series. A hidden plot can still be usable; a displayed label alone does not prove that a corresponding plot exists.
For a hypothetical plot titled Stop Price, an alertcondition() message can use the following named-plot placeholder. The indexed alternative is valid only if you verified that the required output is plot zero. These are plain alert-text examples, not JSON and not executable PickMyTrade order messages.
Stop: {{plot("Stop Price")}}
Indexed alternative, only if verified: {{plot_0}}Create the alert for the intended script instance and observe a controlled realtime event. Compare the resolved number with the output on that trigger bar, not the value displayed much later. Check symbol, timeframe, units and price validity. A value can exist on one bar and be unavailable on another.
For alert() messages, TradingView does not process placeholders in the message argument as it does for alertcondition(). The author normally constructs dynamic text from runtime values, for example by converting a numeric variable to text. Pasting a placeholder into an input does not itself implement expansion; verify the author’s documented processing and emitted result.
Does a changing plot automatically move the broker stop?
No. A stop value sent with an entry represents a value captured for that event. If the indicator later moves its stop line, updating the broker requires a separate supported modification mechanism. It must identify the intended account, instrument and order or position, then receive confirmation of the change.
Decide whether the workflow uses a fixed entry-time stop, a broker-supported trailing rule, or script-driven updates. Document who owns modifications and what happens if an update is rejected or delayed. Avoid sending a new entry merely to change protection. Confirm the accepted broker stop price after each intended modification.
When does the signal become final?
Determine whether the alert fires during a developing bar, at bar close, or after another timeframe confirms. A signal that appears intrabar can disappear before the candle closes. Automation can already have acted on the earlier event even if the final chart no longer displays the same signal.
TradingView’s repainting documentation describes differences between historical and realtime calculations. Ask about higher-timeframe data, pivot confirmation, and drawings placed on earlier bars. “Non-repainting” needs a precise definition: which values are confirmed, when the alert fires, and whether the historical marker shows the actual decision time.
For example, an author may confirm a pivot several bars later and draw the marker on the pivot bar. That does not establish an alert was available on that earlier bar. Compare timestamps from forward alerts with what the chart displayed at the time. Screenshots of historical winners cannot settle that timing question.
Bar-close triggering can reduce unconfirmed intrabar changes, but it does not repair every script design or higher-timeframe dependency. Match the alert frequency to the author’s documented logic. If alert() supplies the event, its programmed timing and filters matter; a dialog setting alone may not control the full behavior.
What should the author provide before you automate?
Ask for a short automation specification that connects each visible signal to an alert, message and timing rule. The author does not need to reveal private calculations to describe those outputs. Clear answers help distinguish a compatible indicator from one that still needs a supported interface added.
- Which alert option should I choose for long, short and each exit?
- Can I enter a custom execution message, or is the message generated inside the script?
- If one alert forwards all events, how are event types distinguished or filtered?
- When does each event become confirmed, including higher-timeframe conditions?
- Can signals disappear or be plotted on an earlier bar after confirmation?
- Which outputs expose stop and target values, and are those values prices or distances?
- Are levels valid on the trigger bar, and how are later changes sent?
- What happens to repeated signals, partial exits and opposite events?
- Which script settings or updates require recreating my running alert?
How do you connect a compatible indicator to PickMyTrade?
Use the documented Indicator setup for the broker you actually connect. For example, PickMyTrade’s ProjectX indicator guide separates Indicator and Strategy workflows and generates the message and webhook for its route. Other connectors have their own fields, supported exits and account settings.
- Connect the intended broker account and confirm its environment.
- Choose Indicator in the applicable Generate Alert workflow.
- Set destination, instrument, quantity and supported protection.
- Generate the broker-specific message and webhook URL.
- Select the indicator’s documented TradingView event.
- Apply the generated message where that interface supports it, or configure the author’s compatible message inputs.
- Verify the outgoing event before enabling the intended execution route.
With separate long and short conditions, each running alert needs the correct action. With script-generated alerts, verify that the script actually emits the connector’s required payload. If it cannot, stop at that compatibility gap and involve the author. A notification saying “LONG” is not equivalent to an authenticated execution request.
TradingView’s webhook documentation says the alert message becomes the HTTP request body. Valid JSON gets an application/json content type; other text is sent as text/plain. JSON syntax alone does not establish that its keys, actions and units are accepted by the destination.
Use a TradingView plan with the necessary alert and webhook features; check the current plan comparison. TradingView requires two-factor authentication for webhook alerts. Keep broker passwords out of the message. Use only the generated integration credentials required for the route, and redact them before sharing logs or asking for help in a public channel.
Worked example: a visible buy signal with a missing exit interface
Consider a hypothetical invite-only indicator with separate Long and Short alert conditions. Its chart also draws a stop line, but the author has not exposed that line as a numeric output. The signals may be usable for entries, while the desired dynamic-stop workflow remains incomplete. These are independent readiness checks.
| Requirement | Hypothetical finding | Next action |
|---|---|---|
| Long/short events | Named alert conditions exist | Verify event meaning and timing |
| Custom message | Message field is editable | Use the generated connector message for each direction |
| Dynamic stop | Drawn line, no accessible numeric level | Ask author for a usable plot/message output or choose a separately defined supported stop method |
| Exit behavior | No separate exit condition documented | Define who closes the position and how |
| Repeats | Unknown | Obtain the rule and test before enabling |
Do not replace the missing stop output with a guessed placeholder. If you choose a fixed-distance stop as an alternative, recognize that you changed the trading plan and must test that plan separately. Successful entry delivery does not establish that the original indicator’s complete visual setup has been automated.
Worked example: a complete entry-time protection plan
Now suppose an author documents a Long Entry condition, an editable alertcondition() message, and numeric outputs for Stop Price and Target Price. The plan allows one long entry from flat, uses broker-held protection, and ignores repeated long events through a verified supported control. This example defines expected behavior; no account test is claimed.
| Component | Illustrative specification | Verification required |
|---|---|---|
| Signal | Long Entry after the documented confirmation | Timestamp agrees with the author’s timing rule |
| Message | Generated Indicator payload for the chosen broker | Named plots resolve in the proper fields; account and symbol match |
| Size | One MNQ contract | Actual position is long one, subject to fill confirmation |
| Entry reference / levels | 20,000 reference; stop 19,990; target 20,020 | Hypothetical prices use valid increments and correct sides |
| Protection ownership | Levels captured at entry; broker holds the accepted exit orders | No assumption that later chart-line changes modify orders |
| Repeat or exit | Supported ignore rule; explicit supported close if needed | No extra entry and no unintended exposure after protection fills |
The reference-to-stop distance is 10 points. If the entry fills elsewhere while the stop remains 19,990, the actual distance changes. Verify accepted protection and quantity at the broker. This is ready for controlled testing only after the connector’s units, order handling and generated configuration are confirmed.
Is the indicator ready, or does it need changes?
| Verdict | Use when | Next step |
|---|---|---|
| Ready for controlled testing | Events, message, timing, size and exits are defined and compatible | Run the forward-test cases below |
| Needs author changes | Required event, numeric output, filter or message control is missing | Request a documented interface; do not guess hidden values |
| Requires a different trading rule | You substitute fixed stops or another exit method for unavailable indicator outputs | Document and evaluate the changed plan before integration testing |
What should you test before enabling the workflow?
Run controlled forward tests in an appropriate demo route. Record the script version, inputs, symbol, timeframe, selected event and expected position change. Then compare the TradingView event, emitted payload, integration record and broker state. A chart marker or successful webhook delivery verifies only part of that sequence.
| Test | Evidence to compare |
|---|---|
| Initial entry | Correct destination, contract, side, quantity and fill state |
| Opposite and repeated events | Actual behavior matches the declared position-management rules |
| Dynamic levels | Placeholders resolve to valid numbers and protection uses the intended prices |
| Early stop/target exit | A later script exit does not create unintended exposure under the selected route |
| Partial fill or partial exit | Remaining quantity and protective orders match |
| Settings update | Replacement alert reflects the intended script inputs and message |
| Missing or rejected order | Logs identify the failure; protection and exposure are inspected |
Use PickMyTrade’s alert monitoring guide alongside broker records. An order accepted for placement is not necessarily filled. Inspect working stops and targets rather than inferring protection from a field in the outgoing JSON. Preserve enough redacted evidence to investigate a mismatch.
Recreate the running script alert after changes to its saved context need to take effect. TradingView’s alert documentation explains that script inputs, symbol and timeframe are captured when the alert is created. Updating the chart does not update that running copy. Retire obsolete alerts deliberately to avoid duplicate routes.
Troubleshooting unresolved values and wrong events
Inspect the actual outgoing message first, then follow the event through the integration and broker. A literal placeholder, missing value, wrong action and duplicate order indicate different problems. Stop unintended new entries while investigating and keep an explicit plan for protection on any existing position.
| Symptom | Check before retrying |
|---|---|
| Placeholder arrives literally | Alert interface, exact syntax and whether the author’s alert() message constructs dynamic values |
| Missing or nonnumeric level | Output exists and is numeric on the trigger bar; plot title/index is correct |
| Wrong plot value | Selected indicator instance, source script, symbol, timeframe and units |
| Wrong action from Any alert() call | Author’s event filters and direction-specific runtime messages |
| Duplicate instructions | Old alerts, repeated intrabar events and overlapping automation routes |
| Chart stop moves but broker stop does not | Whether any modification event was sent and accepted |
| Order rejected | Broker response, account permission, instrument mapping, size and stop validity |
Do not blindly resend an entry after an uncertain response. Inspect the broker’s current orders and position first. If author help is needed, provide the alert option, script inputs, trigger timestamp and timezone, redacted message, expected output and observed output. Never include passwords or integration tokens in public examples.
Frequently asked questions
A compatible indicator can provide signals without exposing its source code. It must offer usable events or outputs and a message interface that works with the selected connector. Check direction, exits, timing and required numeric values. Invite-only access alone neither guarantees nor prevents compatibility.
Labels alone are insufficient evidence. Check for matching alert conditions, script-generated alerts, or usable plot series. A plot-based alert can work where the output represents the intended condition. If the script exposes none of the needed events or values, ask the author to add a supported interface.
It establishes a script-generated alert interface, not message compatibility. Inspect which calls can fire, how direction is identified, and whether the runtime message matches the execution service. Hardcoded human-readable notifications may need changes by the author. Adding a webhook URL does not rewrite their content.
Do not expect strategy order-fill placeholders to supply positions or orders from an indicator script. Use the Indicator workflow and supported market or plot placeholders where applicable. A Pine strategy has a separate broker-emulator order model. Calling a paid indicator a strategy does not give it that model.
Source code is not always necessary if the author exposes valid stop values through supported plots or a compatible generated message. Confirm the value’s units, availability and update timing. A drawing or text label alone does not establish numeric access, and a fixed stop is a different trading rule.
Automate the defined workflow, not just the chart marker
Before you automate an invite-only indicator, identify the event, message, direction, timing, sizing and exit rules. Resolve any missing interface with the author, then follow the TradingView alert setup guide for the supported route. Verify the resulting account position and protection before depending on the workflow.
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: How to Test TradingView Automation Safely Before Going Live
Connect your alerts with PickMyTrade — automated trade execution, no coding required. Start free →