Strategy Hub
Create, configure, activate, and operate Strategy Hub bots with subscription-aware access, runtime protections, DCA support, command builder payloads, and copy-ready examples.
Overview
Strategy Hub is not only a command builder. It is the full operating layer where a user creates bots, assigns them to a platform, selects a symbol, configures signal channel and signal source, applies runtime protections, enables or disables DCA, manages activation state, and finally generates builder-compatible commands for external execution.
This page explains subscription access, active bot limits, bot creation flow, form field meanings, selector behavior, DCA logic, builder output, validation rules, and troubleshooting.
Strategy Hub is not only a screen. It is a feature gated by subscription state, feature enablement, and active-bot limits.
You should understand bot creation, activation, deactivation, editing, and the difference between existing bots and active bots.
Spread, drawdown, deviation, stop loss, take profit, trailing, hidden mode, and weekend behavior all affect execution quality.
The same bot can run as a normal strategy or as a DCA strategy with custom per-order sizing, step, and TP planning.
Strategy Hub can generate copy-ready request formats for POST body mode and GET URL mode.
This page includes examples, validation rules, expected outcomes, and troubleshooting to help you use Strategy Hub correctly.
Subscription & access
Before you click Add New Bot, make sure your subscription allows you to use Strategy Hub. Your plan may control whether the feature is enabled, whether bot creation is allowed, whether editing is allowed, and how many bots can be active at the same time.
Strategy Hub access depends on subscription state, plan activation, expiration state, and whether the Strategy Hub feature is enabled in the plan.
Existing bots and active bots are not always the same. Plans often limit active bots, not only created bots.
Create, edit, and activate permissions may be checked separately by backend state. A user may be allowed to view or edit but not activate more bots.
If your subscription does not include Strategy Hub access, you should not expect bot creation or activation to work.
Your plan may allow only a limited number of active Strategy Hub bots. You may be able to create more bots, but you may not be able to activate more than your plan limit.
Your create access, edit access, and activate access can be controlled separately by the backend state.
If the active limit is reached, the correct action is usually to deactivate another bot or upgrade the subscription.
Create bot flow
Recommended flow: first verify your subscription access, then click Add New Bot, configure the bot carefully, save it, and activate it only if your subscription still allows another active Strategy Hub bot.
Make sure Strategy Hub is enabled in the user plan.
Create a new bot and fill the configuration form.
Choose platform, symbol, DCA, limits, and management rules.
Use the builder to generate POST body or GET URL.
Activate the bot and monitor execution state and limits.
The user must have an active plan with Strategy Hub access and enough allowed active bots.
The user clicks New Bot and fills the configuration form carefully.
Platform, symbol, DCA, limits, and routing must be saved before runtime execution.
After saving and validating limits, the bot can be activated if the plan allows it.
Signal Builder
The Strategy Hub builder is action-first. You choose what should happen, add only the parameters needed for that action, select how the request should be routed, and then copy either the generated POST body or the GET URL.
Bot form reference
The create/edit form defines the runtime behavior of your bot. This is where you set the destination account, symbol, signal policy, DCA rules, spread and deviation filters, stop logic, trailing logic, time windows, and drawdown protection.
The user chooses the exact destination account.
Controls whether the bot accepts API/webhook/manual flow.
Used for tracking, labeling, and analytics.
Defines how DCA averaging behaves.
One symbol per bot is the cleanest operating model.
Builder output can be generated as POST body or GET URL.
Basic fields
The destination broker/exchange account that will receive execution.
Human-readable name for your strategy. It should clearly describe the symbol, style, or use case.
Controls whether the bot accepts webhook/API requests, manual trades, or both.
A label describing where your signal came from, used for routing, analytics, or clearer support tracking.
Using one symbol per bot is the recommended operational rule. This keeps your execution and debugging cleaner.
Controls whether the bot is currently active and able to execute signals.
Risk & runtime fields
Maximum acceptable difference between signal price and broker price before execution is blocked.
Maximum spread allowed before execution is blocked.
Limits how many open trades the bot may have. When DCA is enabled, this becomes the number of DCA orders per cycle.
Enable or disable take profit handling.
Enable or disable stop loss handling. Disabled automatically by some modes such as trailing or DCA.
Acts as stop loss in normal mode and as DCA step in DCA mode.
Take profit in points.
Virtual SL/TP handling. The broker does not see SL/TP orders directly; the bot manages them internally.
Enables dynamic stop management while price moves in favor of the position.
How often the trailing logic updates, measured in points.
The distance kept between price and stop while trailing mode is active.
Optional start time in HH:MM format.
Optional end time in HH:MM format.
If enabled, the bot closes positions before markets close for the weekend.
Used to derive stop-out equity protection based on current/baseline equity.
Base lot size used for non-DCA execution or as the default size for DCA rows.
Optional comment attached for easier identification and audit.
DCA & custom plan
Turns the bot into a DCA strategy instead of a single-entry strategy.
Defines whether the averaging logic works in Negative, Positive, or Both directions.
Allows per-order configuration for lot size, step, and take profit.
Comma-separated per-order lot sizes stored by the backend when custom plan is enabled.
Comma-separated per-order step distances. The last row step is ignored.
Comma-separated TP values per row when using a custom plan.
Supported actions
Parameter reference
Execution channels
Use POST when you want to send a raw text body generated by the builder.
BUY, VOL=0.10, SL=250, TP=500, TPSLType=PIPS
Use GET when the request is easier to send as query parameters.
/webhooks/{botId}?action=BUY&vol=0.10&sl=250&tp=500&tpsltype=PIPSExamples
Simple POST body for opening a BUY trade.
BUY, VOL=0.10, SL=250, TP=500, TPSLType=PIPS, COMMENT=AI_XAU_BOTRisk-based sizing instead of fixed lot.
SELL, RISK=1.25, SL=35, TP=70, TPSLType=PIPS, COMMENT=EMA_SELLPending orders should include PRICE.
BUYSTOP, PRICE=2050.00, VOL=0.03, SL=12, TP=24, TPSLType=PIPSUse TICKET when closing one exact trade.
CLOSE, TICKET=12345678, COMMENT=MANUAL_CLOSEUse MODIFY to update stop loss and take profit.
MODIFY, TICKET=12345678, SL=20, TP=40, TPSLType=PIPSEquivalent GET mode request.
/webhooks/{botId}?action=BUY&vol=0.10&sl=250&tp=500&tpsltype=PIPS&comment=AI_XAU_BOTValidation rules
Troubleshooting
Usually the current subscription does not allow Strategy Hub creation, or Strategy Hub itself is disabled in the plan.
The most common reason is that the active Strategy Hub bot limit in the plan has already been reached.
That is expected when signal channel is set to All, because the current logic forces source to Auto.
That is normal. In DCA mode, Stop Loss becomes a DCA step, Take Profit handling changes, and some toggles become constrained.
That is expected behavior in the current form logic. Trailing mode disables normal stop loss handling.
Custom DCA rows should match the required row count, and the last step is ignored automatically by design.