Common Parameters

Overview#

These parameters modify how a signal is identified, when it executes, or whether the EA is permitted to trade at all. Unlike command-specific parameters, these can appear on many or all signal types.

Misuse of any one of them can block a signal outright (active hours with an invalid format is rejected with HTTP 400), or strand signals in a queue (delay on a trial account is rejected at the gate). The most common issues involving these parameters are: trades that do not execute despite signals being accepted; EAs that stop trading entirely after an emergency command; delayed signals that appear to vanish; and pending orders that expire at unexpected times.

---

Parameters at a Glance#

---

Trade Identification#

The magic Parameter#

The magic parameter assigns a numeric identifier to a trade. Whether it is used depends on the Magic Number Mode configured in the EA's input dialog in MetaTrader 5. This is not a dashboard setting.

How the server learns the mode: The EA reports its Magic Number Mode to the server when it connects. If you change the mode in MetaTrader, it takes effect on the EA's next connection; until then the server may act on the previous value. Until the EA has connected on a license, magic requirements are not enforced (fail-open).

---

Magic Values: ALL, 0, and N#

The magic value has three distinct forms:

• magic=N (a positive integer) — targets only positions or orders stamped with that exact magic number (one strategy).
• magic=0 — targets only magic-0 trades, which are manual trades: MetaTrader stamps magic 0 on any position not opened by an Expert Advisor. 0 is a literal magic ID, not a wildcard.
• magic=ALL — the wildcard: targets every magic (all strategies) on the scope. This is the only way to spell "all magics." It is valid only on close, cancel, and modify commands — an opening command must use a concrete magic.
• Omitting magic — uses your default magic in Single mode; on a targeted command in Multi-Strategy mode it is rejected (be explicit with magic=N or magic=ALL).

Negative magic values (for example magic=-1) are rejected with an HTTP 400 — ALL is the only spelling for the wildcard.

---

Single Mode (Default)#

In Single mode, the magic value in any signal is completely ignored. Every trade the EA opens uses the Default Magic Number configured in the EA input dialog. Close and modify commands only affect positions carrying that default magic. They never touch positions opened by other software or manual trades.

Example: A buy signal with magic=99999 opens the trade with the EA's configured default magic, not 99999. A closelong signal closes only longs with the default magic.

---

Multi-Strategy Mode#

In Multi-Strategy mode, the magic parameter is fully active. Every open command (buy, sell, buylimit, buystop, selllimit, sellstop, buyat, sellat) must include a magic number. Signals that omit magic on these commands are rejected with HTTP 400.

How many strategies you can run per symbol: each license can hold positions from a limited number of distinct magic numbers on any one symbol. The allowance is 2 on Trial, 2 on Standard, 5 on Pro, and 10 on Premium. It applies per symbol rather than per license, so a Pro license trading five symbols can run up to 25 strategies at once, five on each. Only Multi-Strategy mode is affected, because in Single mode every trade shares one magic number and you will never reach it.

Once a symbol is at its allowance, an open command using a new magic number is rejected with "Position limit reached for this symbol". That message means the strategy allowance and not the Max Long/Short Lots limits, which are separate EA settings. Strategies already holding a slot keep trading normally. A slot frees up once a magic number has no open position left on that symbol, so a partial close, or closing one leg of a hedge, keeps the slot until the last leg is closed. See Subscription Tiers for the full breakdown.

To act on every strategy's positions at once, pass magic=ALL (the explicit wildcard). A symbol-scoped targeted close/cancel/modify that omits magic entirely is rejected in Multi-Strategy mode — be explicit about whether you mean one strategy (magic=N), manual trades (magic=0), or all of them (magic=ALL).

Commands that require magic in Multi-Strategy mode: All open commands plus all targeted commands: closelong, closeshort, modify, breakeven, trail, notrail, nobreakeven, cancellong, cancelshort, and their counterparts.

Commands that bypass magic enforcement in every mode: the symbol-less (kill-switch) forms of the sweep commands, the always-global closealleaoff and closecancelalleaoff, and the EA toggle commands (eaon, eaoff, eaoffexcept, eaonexcept). Note the scope condition: in Multi-Strategy mode a symbol-scoped, magic-less closeall, cancelall, closecancelall, closeallprofit, or closeallloss is rejected with HTTP 400, so only the symbol-less form of those sweeps skips the magic filter. A symbol-scoped, magic-less clearqueue is likewise rejected in Multi-Strategy mode (and whenever the server cannot confirm Single mode); only clearqueue,ALL and the symbol-less form are magic-optional.

---

The Symbol-Less Kill-Switch Exception#

When a close or cancel command is sent without a symbol (for example, a closeall with no symbol field in the payload), it becomes a terminal-wide emergency brake. This form bypasses both the symbol filter and the magic filter in every mode, closing every position and cancelling every pending order on the MT5 terminal, including positions opened by other Expert Advisors and manual trades. This is intentional behavior for emergency use only.

---

Where the Magic Rejection Appears#

When a signal is rejected for missing magic in Multi-Strategy mode, it appears in two places:

1. Signal Logs → Rejected Signals tab in the dashboard, with the offending field highlighted and the reason shown. Row creation requires the platform to have extracted a valid license from the payload. Very long messages may be shortened.
2. TradingView alert execution status, since the HTTP 400 response is returned directly to the webhook caller.

---

Signal Formats: magic#

CSV: append magic=12345 to any signal as a trailing field.

JSON: add "magic": 12345 to the signal object.

---

Time Parameters#

delay: Server-Side Signal Delay#

The delay parameter holds a signal on the server for a specified number of seconds before dispatching it to the EA. The signal is queued in persistent storage and survives server restarts; it fires automatically when the scheduled time arrives.

---

How Delay Works#

The delay value is an integer number of seconds. The maximum is 86,400 (24 hours). Values above this are rejected with HTTP 400 and recorded in Signal Logs → Rejected Signals tab; the signal does not enter the queue. Negative values are also rejected with HTTP 400 (use 0, or omit delay, for immediate dispatch).

The countdown starts from the moment the server receives the signal, not from when TradingView fired the alert. Network latency between TradingView and the server is not included in the countdown.

When a delayed signal is accepted, the server responds with the scheduled execution time in UTC ISO 8601 format (the execute_at field), so you can verify the intended fire time.

Delayed signals automatically expire if they have not fired within 28 hours of receipt, as a safety measure against orphaned entries.

Delay is timezone-independent: it is a relative offset from server receipt time, with no timezone calculation required.

---

Plan Requirement#

Delay requires a Standard, Pro, or Premium subscription. Trial accounts that send a signal with delay greater than zero receive HTTP 402 with the message: "Delayed signals require a paid plan. Upgrade to use delay=."

---

Queue Ceiling#

Each paid plan has a per-license limit on how many delayed signals may be queued simultaneously:

When this ceiling is reached, subsequent signals with delay receive HTTP 429. The response includes an X-Delayed-Queue-Depth header showing the current queue depth. The queue drains as each signal fires, expires, or is cleared via clearqueue.

---

How Delay Interacts with Other Parameters#

• delay + expiry or expiry_time: The expiry countdown begins when the EA places the order, after the delay fires, not when TradingView sent the alert. A 30-second delay plus a 60-second expiry means the pending order lives for 60 seconds starting 30 seconds after the alert was sent.
• delay + active_start / active_end: Active hours are checked at the EA when it receives the dispatched signal, not at server dispatch time. A signal queued during active hours will be silently dropped by the EA if the delay is long enough to push dispatch past the active_end boundary. The server accepts and queues the signal normally; no error is returned to TradingView. The EA logs the rejection locally. Avoid pairing long delays with tight active hours windows.
• delay does not interact with the EA filter: Symbol filter and magic mode enforcement run at signal receipt time, not at dispatch time. If the signal was valid when queued, it dispatches without re-validation.

---

Signal Formats: delay#

CSV: append delay=30 to any signal.

JSON: add "delay": 30 to the signal object.

---

expiry and expiry_time: Pending Order Expiration#

These parameters set a deadline after which an unfilled pending order is cancelled. The two parameters use different cancellation mechanisms:

• expiry (seconds): EA self-managed. The order is placed as Good Till Cancelled (GTC), and the EA cancels it via an internal timer when the deadline arrives. Works on any broker regardless of native order-expiry support.
• expiry_time (ISO 8601 datetime): Broker-native. The order is submitted with a specific expiration timestamp directly to the broker. Requires the broker to support native order expiry (ORDER_TIME_SPECIFIED). On brokers that do not support this, behavior is broker-defined.

Applies only to pending orders: buylimit, buystop, selllimit, sellstop, buyat, sellat. Sending expiry on a market order (buy, sell) has no effect; the value is accepted but silently ignored.

Priority when both are provided: expiry_time takes precedence over expiry. If neither is provided, the order remains open until filled or cancelled (Good Till Cancelled), subject only to the per-license pending order ceiling described below.

---

expiry (seconds)#

A positive integer representing seconds from the moment the EA places the order. The order is placed GTC; the EA's internal timer cancels it when the deadline elapses. Very small values (under a few seconds) risk the order being cancelled before the EA can confirm it has filled.

Trial accounts: capped at 900 seconds (15 minutes). Any expiry value above this returns HTTP 402 and is recorded in Signal Logs → Rejected Signals tab.

Paid accounts: up to 86,400 seconds (24 hours). Values above 86,400 are rejected with HTTP 400 for every tier (including Premium) and are recorded in Signal Logs → Rejected Signals tab. There is no plan above the 24-hour cap.

---

expiry_time (ISO 8601 datetime string)#

A specific datetime at which the pending order expires, passed directly to the broker. The broker handles cancellation natively.

Timezone handling: expiry_time is interpreted as UTC. A bare or Z-suffixed timestamp is UTC; an explicit ±HH:MM offset is honored and converted to UTC; the EA then converts the resulting UTC instant to broker server time for placement. So the order expires at the correct real-world moment regardless of the broker's timezone. (Fractional seconds, if present, are ignored.)

This means:

• 2024-01-15T14:30:00: bare = UTC; resolves to 14:30:00 UTC, placed at the equivalent broker-server time.
• 2024-01-15T14:30:00Z: Z = UTC; same instant as the bare form.
• 2024-01-15T14:30:00+05:00: the offset is honored → 14:30 at UTC+5 = 09:30 UTC, placed at the equivalent broker time.

How to write the time you want (all expire at the 14:30 figure):

Timezone recommendation: When in doubt, send expiry_time in UTC (bare or Z), or use expiry (seconds), which is offset-independent. Use an explicit ±HH:MM offset only when you specifically want a broker-local or exchange-local wall-clock time.

The same 15-minute trial cap applies to expiry_time: if the resolved time is more than 15 minutes in the future, trial accounts receive HTTP 402. For all tiers, an expiry_time that resolves to more than 24 hours in the future is rejected with HTTP 400. Both rejections are recorded in Signal Logs → Rejected Signals tab.

---

Per-License Pending Order Ceiling#

A separate per-plan limit applies to how many unfilled pending orders a license may have active simultaneously. This is the platform's anti-spam ceiling: it caps how many pending-order signals can be in flight at once.

This ceiling is enforced per license only: there is no platform-wide global cap on pending orders. Each license is tracked independently.

When the ceiling is reached, new pending order signals receive HTTP 429, and the response includes an X-Pending-Order-Count header.

A slot frees the moment its order fills or you cancel it (cancellong, cancelshort, or cancelall). Orders with a declared expiry / expiry_time also free their slot when that time passes.

Set an expiry on your pending-order signals so your ceiling stays clear even if a fill notification is ever missed. A pending order with no expiry still works normally at your broker and fills whenever price reaches the trigger; the ceiling is platform-side accounting only and never cancels or alters your broker order.

---

Signal Formats: expiry and expiry_time#

CSV examples:

LICENSE,buylimit,EURUSD,price=1.0800,sl_pips=30,tp_pips=60,expiry=3600

LICENSE,selllimit,XAUUSD,price=2050.00,sl_pips=50,tp_pips=100,expiry_time=2024-01-15T14:30:00Z

JSON examples:

{"license": "LICENSE", "action": "buylimit", "symbol": "EURUSD", "price": 1.0800, "sl_pips": 30, "expiry": 3600}

{"license": "LICENSE", "action": "buylimit", "symbol": "EURUSD", "price": 1.0800, "expiry_time": "2024-01-15T14:30:00Z"}

---

closetime: Time-Based Position Close#

The closetime parameter automatically closes a position a specified number of seconds after it opens. The countdown begins from the position's open time as recorded by the MT5 broker (broker server time), not from when the server received the signal.

---

How closetime Works#

Valid range: 1 to 2,592,000 seconds (1 second to 30 days). Values outside this range are rejected with HTTP 400 and recorded in Signal Logs → Rejected Signals tab; the whole signal is rejected (no trade is placed). The rejection reason reads: "Invalid value 'N' for closetime - must be between 1 and 2592000 seconds (1 second to 30 days)".

The timed close is tracked on the EA side and persisted to disk, surviving EA restarts. When the EA restarts, it reloads the timer record, checks the position's original open time, and calculates the remaining duration from that baseline.

If the position closes before the timer fires (stop-loss hit, take-profit reached, or manual close), the timed close is automatically cancelled. No stray timer fires after the position is gone.

closetime coexists with trailing stops, multi-TP targets, and auto-breakeven. Each feature operates independently. Whichever condition closes the position first also cancels the others.

---

Timing Note#

The close fires on a tick. If the market is illiquid or the MT5 terminal is disconnected at the exact close time, the close fires on the next available tick after connectivity restores. Fills at close time in volatile conditions are subject to normal broker execution and slippage rules.

---

Signal Formats: closetime#

CSV:

LICENSE,buy,EURUSD,size_pct=1,sl_pips=50,tp_pips=100,closetime=3600

JSON:

{"license": "LICENSE", "action": "buy", "symbol": "EURUSD", "size_pct": 1, "sl_pips": 50, "closetime": 3600}

---

active_start and active_end: Per-Signal Active Hours Override#

These two parameters let a signal override the configured active hours window for that one delivery only. When included, the EA checks the current time against this window instead of the configured window. The override is scoped to the signal's license: it never affects another license on the same account, even if you have multiple licenses connected.

Both bounds are required together. If the signal includes active_start without active_end, or active_end without active_start, the platform rejects it with HTTP 400 and writes a row to Signal Logs → Rejected Signals. The previous behavior silently filled the missing side from the configured per-license setting, which combined a typo with the configured window and produced a window the user did not intend.

---

Scope and Persistence#

The override applies to the single signal it accompanies. It has no persistent effect. The global setting resumes immediately after the signal is processed.

Only entry signals are subject to active hours enforcement: buy, sell, buylimit, buystop, selllimit, sellstop, buyat, sellat. Close, cancel, modify, trail, breakeven, and management commands are never blocked by active hours, whether global or per-signal.

---

Format Requirements#

Both parameters must be exactly HH:MM in 24-hour format with leading zeros.

Valid examples: 09:00, 00:00, 17:45, 23:59.

Invalid examples (all rejected with HTTP 400): 9:00 (missing leading zero), 9:0 (missing leading zero on minutes), 25:00 (hour out of range), 12:60 (minutes out of range), 09-00 (wrong separator).

When a value is invalid, the whole signal is rejected with HTTP 400 and a row is written to Signal Logs → Rejected Signals, with the reason noting the value must be HH:MM, 24-hour, with leading zeros (e.g. 09:00, 23:59). The signal is not delivered and no trade is placed. (This is the current behavior: a malformed active-hours bound used to be silently dropped, which removed the active-hours gate without any diagnostic.)

---

Timezone#

The time comparison uses whichever timezone is configured in the EA's active hours timezone setting: Server (default), UTC, or Local. This is an EA-level setting, changeable via the input dialog or the dashboard depending on the EA's settings source. A per-signal active_start / active_end override uses the same timezone as the EA setting; it cannot specify a different timezone per signal. If the EA is set to Server time and the broker is GMT+2, active_start=09:00 means 09:00 broker server time, which may differ from your local time.

---

Partial Overrides#

If only active_start is provided without active_end (or vice versa), the signal is rejected with HTTP 400. The platform does not fill the missing side from the per-license configured value. Both parameters must always be provided together. The rejection appears in Signal Logs → Rejected Signals tab with the parameter pill set to whichever bound was supplied.

---

End Time Is Exclusive#

The active_end value is the moment the window closes, not the last allowed minute. Setting active_end=17:00 means trading is allowed through 16:59:59 and the window shuts at 17:00:00 sharp. This matches the way time ranges are typically read ("9 to 5" stops at 5:00) and makes the EA's close_outside_hours auto-close fire at the time you wrote rather than one minute later.

Concrete examples:

Common mistake from the inclusive-end era: writing active_end=23:59 to mean "until end of day." Under the new exclusive rule, that ends the window at 23:59:00, blocking the final minute. Use 00:00 for true end-of-day, or write the exact close time you mean.

---

Overnight Sessions#

A window where active_start is later in the day than active_end (for example, 22:00 to 06:00) is correctly interpreted as a session crossing midnight. The same exclusive-end rule applies: 22:00-06:00 means trading is active from 22:00:00 tonight through 05:59:59 tomorrow.

---

Interaction with close_outside_hours#

The close_outside_hours EA setting closes all positions when the EA's configured active hours window ends. A per-signal active_start/active_end override does not change when this closure fires. The closure is tied exclusively to the globally configured hours. A position opened via an extended per-signal override will still be closed at the end of the global window if close_outside_hours is enabled.

---

Signal Formats: active_start and active_end#

CSV:

LICENSE,buy,EURUSD,sl_pips=50,tp_pips=100,active_start=09:00,active_end=17:00

LICENSE,buy,USDJPY,sl_pips=30,active_start=22:00,active_end=08:00

JSON:

{"license": "LICENSE", "action": "buy", "symbol": "EURUSD", "sl_pips": 50, "active_start": "09:00", "active_end": "17:00"}

---

clearqueue: Clear the Server-Side Delayed Signal Queue#

The clearqueue command removes queued delayed signals from the server's dispatch queue before they fire. It operates entirely on the server and does not touch broker-side pending orders or any positions.

This command was renamed from canceldelay. Signals using the old name receive an error response directing you to update the alert template to use clearqueue.

What clearqueue affects: Only signals submitted with a delay parameter that have not yet fired. Active positions and pending orders on the broker are completely unaffected. To cancel broker-side pending orders, use cancellong, cancelshort, or cancelall.

clearqueue does not require a magic number for the symbol-less form or clearqueue,ALL. A symbol-scoped clearqueue (for example clearqueue,EURUSD) without magic is rejected with HTTP 400 in Multi-Strategy mode, and also whenever the server cannot confirm the EA is in Single mode. Add magic=N to scope it, or use ALL (or omit the symbol) for a cross-strategy clear.

---

Signal Formats: clearqueue#

Clear queued signals for a specific symbol:

LICENSE,clearqueue,EURUSD

Clear queued signals for a symbol, filtered by magic number:

LICENSE,clearqueue,EURUSD,magic=12345

Clear all queued signals for this license:

LICENSE,clearqueue,ALL

On success, the server responds with the count of signals removed.

---

Cross-Parameter Interactions#

---

Error Messages and Meanings#

Validation Errors (HTTP 400)#

Surface: Signal Logs → Rejected Signals tab in the dashboard. Also returned directly to the webhook caller (visible in TradingView alert execution status). Row creation in Rejected Signals requires the platform to have successfully extracted a valid license from the payload. Very long rejection reasons may be shortened.

Tier Gate Errors (HTTP 402)#

Surface: Signal Logs → Rejected Signals tab. Also returned to the webhook caller.

Queue and Rate Limit Errors (HTTP 429)#

Surface: Returned to the webhook caller. If the license was resolved, the signal also appears in Signal Logs.

Malformed-Parameter Rejections (HTTP 400)#

A malformed value on any of these parameters rejects the whole signal with HTTP 400. No trade is placed. A row is written to Signal Logs → Rejected Signals (provided a valid license was extracted from the payload), with the offending parameter highlighted.

EA-Side Blocks: MetaTrader Experts Tab and EA Support Log File#

These are not server errors. They occur after the signal has been accepted by the server and delivered to the EA.

---

Signal Logs Status Pills for Time-Parameter Issues#

The Signal Logs row's status pill is the fastest way to triage a time-parameter problem. The mapping below is specific to the parameters covered in this article.

---

Where to look#

---

Plan and Tier Differences#

When the delayed signal queue ceiling is reached: Subsequent signals with a delay parameter return HTTP 429. The X-Delayed-Queue-Depth header in the response shows the current count. The ceiling drains as signals fire, expire, or are removed via clearqueue.

When the pending order ceiling is reached: New pending order signals return HTTP 429 with an X-Pending-Order-Count header. The ceiling drains when the EA reports the order filled, when declared expiry times pass, or when orders are explicitly cancelled via cancellong / cancelshort / cancelall. The fill path is the primary drain for an actively trading strategy; expiry and explicit cancel are fallbacks.

When a subscription lapses mid-session: Signals already in the delayed queue continue to fire; they were accepted during an active paid subscription. New signals with delay greater than zero are rejected with HTTP 402 until the subscription is renewed.

---

Known Edge Cases and Gotchas#

• A signal with delay=0 executes immediately. It does not enter the queue and does not require a paid plan.
• closetime counts from the position's open time in broker server time, not from when TradingView sent the alert. On a delayed signal, the gap between alert and position open time equals at minimum the configured delay.
• In Multi-Strategy mode, a symbol-scoped targeted close/management command without a magic is rejected. Use magic=N to scope to one strategy, or magic=ALL to act on every strategy's matching positions.
• Symbol-less closeall (no symbol in the payload at all) bypasses both the symbol filter and the magic filter in every mode. It closes every position on the terminal including those opened by other Expert Advisors and manual trades.
• Per-signal active_start/active_end overrides do not affect the close_outside_hours behavior. The global active hours trigger that behavior; individual signal overrides have no influence on when positions are closed.
• If only active_start or only active_end is provided in a signal, the platform rejects the signal with HTTP 400 (no silent fallback). Both bounds must always be supplied together, or both omitted. Per-signal active-hours overrides are scoped to the signal's license only: they never affect other licenses on the same account.
• When the EA has never connected on a license (or has not connected since Multi-Strategy mode was enabled), the server has no cached mode and applies fail-open behavior; magic is not enforced. Magic enforcement begins with the first EA connection after the mode is set.
• clearqueue and cancellong/cancelshort/cancelall are completely independent operations at different layers. You must use both if you want to simultaneously drain the server queue and cancel broker-side orders.

---

Frequently Asked Questions#

Q: I'm in Multi-Strategy mode and sent a close command without a magic number, and it closed positions from another strategy. Is this a bug? A: In Multi-Strategy mode, a symbol-scoped targeted command (closelong, closeshort, modify, etc.) without a magic is rejected — be explicit. Use magic=N to scope to one strategy, or magic=ALL to act on every strategy's positions.

Q: I set expiry=300 but the pending order did not expire after 5 minutes. Why? A: PineHook's expiry is EA-managed. The EA must be running and connected for the cancellation to execute. If the EA went offline before the expiry fired, the order remained open on the broker until the EA reconnected and then processed the expiry. Ensure the EA runs continuously when using expiry.

Q: My clearqueue ran successfully but the pending orders on my broker are still there. Is something broken? A: No. clearqueue only drains the server-side delayed signal queue: signals that were submitted with a delay parameter but have not yet fired. It has no effect on the broker's order book. Use cancellong, cancelshort, or cancelall to cancel broker-side pending orders.

Q: I sent active_start=09:00 but trades at 10:00 are still being blocked. What could be wrong? A: Confirm the format is exactly HH:MM including a leading zero (09:00, not 9:00). Also check the EA's configured timezone; if the EA is set to Server time and the broker is GMT+3, a 09:00 window means 09:00 broker server time, which may not align with your local clock. Finally, confirm both active_start and active_end are present in the signal; if only one is supplied, the signal is rejected with HTTP 400 (both bounds must be sent together, or both omitted).

Q: Can I use delay and expiry together? A: Yes. The delay controls when the server dispatches the signal to the EA. The expiry countdown starts from when the EA places the order on the broker; after the delay fires. For a 30-second delay and a 60-second expiry, the order lives for 60 seconds starting 30 seconds after the original alert.

Q: What happens to my queued delayed signals if my subscription lapses? A: Signals already in the queue continue to fire; they were accepted while the subscription was active. New signals with delay greater than zero are rejected with HTTP 402 until the subscription is renewed.