Signal Parameters

buyStopPrice
buyTTL
DCAAmountPercentage1
DCATargetPercentage1
DCATargetPrice1
DCAPriority
Exchange
key
limitPrice
Market
MDXXXXXX
orderType
orderType = multi
positionSizePercentage
positionSizeQuote
postOnly
price

reduceOrderType
reduceTargetPercentage
reduceAvailablePercentage 
reduceRecurring
reducePersistent 
removeAllReduceOrders
removeReduceOrder 
removeReduceRecurringPersistent 
removeDCAs
removeTakeProfits
panicBase
panicQuote
risk
sellTTL
signalId
stopLossFollowsTakeProfit

Entry

Mandatory fields:

• key
• exchange
• pair
  
  
• signalId
  in order to identify this position to send another command to exit or update
• Copytrader & Profit-Sharing Providers: you must include positionSizePercentage 
  to entry signals
  
  

Entry signals allow you to send signals for opening positions. This will open the position on Zignaly, and also, will send the buy order to the exchange. Buy orders can be limit, market, or stop-limit, based on the orderType parameter.

This is the default signal, if you don't specify any type parameter, then entry is assumed.

Example explanation:
In this example we are sending an "Entry" signal. For this type of signal, the "signalID" is not mandatory if we send our TP, SL or other parameters included in this Syntax.

On the other hand, if we plan to send "Update" or "Exit" signals, it is extremely important that we indicate a "signalID" in order for the next signal to identify which position & apply these instructions to the position.

In the event that we decide to send signals to the futures market, it is important that we indicate the direction of the trade, if we want it to be a long or a short position.

Sell / Exit

Mandatory fields:

• key
• type
• pair
• exchange
• signalId

Exit signals identify previously opened positions (with the signalId parameter) and close them sending an exit order to the exchange.

The order is for 100% of the remaining position amount, and the type of exit order that can be sent to the exchange is market or limit (based on orderType).

Example explanation:

In this example we are sending an "exit" signal to a position that we have open in our Zignaly exchange. As you have to find the current position that is open and close it, it is extremely important that the position has "signalID" and we put that ID in our signal in the "signalID" field.

In the following example, we've indicated to exit this position by Market order, adding "orderType": "market", this is not a mandatory field, so it is optional.

For Signal Providers: To accept exit signals, users connected to this provider need to check the Accept Exit Signals option:

ReEntry

Mandatory fields:

• key
• type
• pair
• exchange
• signalId

ReEntry (or DCA) signals identify previously opened positions (with the signalId parameter)
and enlarge their positions' size.

Example explanation: This is a valid case only for signal providers. When they reach certain price levels they decide to send a reEntry or DCA signal to optimize the money management of the position.

The new buy order is sent to the exchange and will be a buy limit order; if no price is specified in the signal, the current price will be used as the limit price.

The new amount is based on the user configuration. And the option of Accept DCA/ReBuys Signals option needs to be checked by the user in the provider's options:

Stop

Mandatory fields:

• key
• type
• exchange

Example explanation:
Let's imagine that we need our provider to stop receiving signals since we detect that the market is very volatile, or some news that may affect us comes to light.

By sending this signal, we would stop opening new positions, but we would continue to manage the ones we already have. That is why we do not need to put the fields of pair, signalID, etc.

Start

Mandatory fields:

• key
• type
• exchange

Start signals will resume accepting signals for a previously stopped provider.

Example explanation:

It is the case totally opposite to the previous one, the market returns to normal and we want to receive signals again. So we apply the same signal by changing the "Type" from "stop" to "start".

DisableMarket

Mandatory fields:

• key
• type
• exchange
• market

DisableMarket signals will make your provider not accept any new buy signal for the given market.

All other signals are accepted (reBuy, sell). It works like the stop signals, but for a specific market.

Example explanation:

This allows us to do exactly the same as the stop parameter, with the only difference that it allows us to focus on a single pair and not on the entire operation of our provider. In this case, it is essential to place the pair we want to stop, but remember that we will continue to receive signals for our DCAs or for exits.

EnableMarket

Mandatory fields:

• key
• type
• exchange
• market

EnableMarket signals will resume accepting signals for a previously disabled provider in the given market.

Example explanation:

As with the "stop" and "start" parameters, it occurs with "disableMarket" and "enableMarket". It allows us to return to normal once we consider it appropriate.

PanicSell

Mandatory fields:

• key
• type
• exchange

PanicSell signals are used to sell everything at the current market price. You can filter by quote or base if you want to delimit it.

Example explanation:
Suppose we decide to close all our positions, either because of some news that we have seen, or because our operations have been compromised. In that case, we send this signal, it is not necessary to specify "pair" or "signalID", since we will close all our open trades.

For Signal Providers:

To accept panicSell signals, the user has to have the following option checked in the provider's option Accept panic sell signals from this provider

Update

Mandatory fields:

• key
• type
• exchange
• pair
• signalId

Example explanation:

Suppose we have an open trade in our dashboard in Zignlay, but we want to modify our Stop Loss. Here if it is important to place the "signalID" so that it identifies the position we are looking to update.

For Signal Providers:

Update signals allow you to update open positions if the user accepts update signals:

Accept Updates from Signals option

The parameters that can be updated are:

• buyTTL (Only for positions where the buy order isn't filled yet).
• sellByTTL
  
  
• stopLossPercentage: Attention, you need to send it as a negative value (example: -5), if not, it will place a positive stop loss value, meaning that if the current price is below it, the position will be sold.
  If you want to place a positive value, then no symbol is needed.

• trailingStopTriggerPercentage
• trailingStopDistancePercentage
• reBuyTargets: You can add as many DCAAmountPercentageX, DCATargetPercentageX (or DCATargetPriceX instead of percentage) as you want. Remember that an already done target can't be updated (even if it has failed).

• takeProfitTargets: You can add as many takeProfitAmountPercentageX, takeProfitPercentageX (or takeProfitPriceX) as you want. *when you send an update signal adding new TP targets, it will remove the previous ones

• removeDCAs: removes any current pending DCA targets (removeDCAs=true)
• removeTakeProfits: removes any current pending Take Profit targets (removeTakeProfits=true)

cancelEntry

Mandatory fields:

• key
• signalId
• pair
• exchange
• type

cancelEntry type will remove an entry signal that has not been filled yet.

For example, if your entry was using a limit order, it will be removed from the exchange.

Example explanation:

Suppose we send an entry limit signal, and for some reason, we see that it will not complete because the price moved away from the zone we established. We can send a signal to cancel that entry.

.

.

reverse

Mandatory fields:

• key
• exchange
• exchangeAccountType
• pair
• signalId

The signal works as an exit and an entry signal
 It will exit the given position, then once it is done and the accounting is performed, it will open a new position.

You can use any parameters in this signal that is available for either exit or entry, but if you want to use the same parameter for the exit and the entry, but with different values, add the prefix "exit" or "entry" to the parameter.

For example, if I want to exit with "market" but I want to enter with "limit", then I need to use
exitOrderType=market and entryOrderType=limit

• exitOrderType
• entryOrderType

You could also apply any other parameter that is allowed in an Entry signal. The same applies for the exit signal:

• exit***
• entry***

The accounting process is what will trigger the buy, so, if there is an open position, it will wait until it is closed and accounted for, then send the entry signal.

If there isn't an open position for exiting, it will open a new one, creating an entry signal immediately.

Example explanation:

Suppose we want that if the trend reverses, we can close the trade that we have open and immediately open one in the new direction. For that, we have to use a reverse signal, and configure the parameters so that it leaves a position and opens the opposite operation.

This is a complex syntax, and we have to configure entry and exit parameters at the same time. That is why we use “exitSide":"short" and "entrySide":"long", for this example.

buyStopPrice

buyTTL

For Signal Providers: If any is provided, the one from the user's settings will be used. If the order was partially filled, the rest of the order would be canceled, and the position will remain with the partially filled amount.

Even if you don't send this value and is disabled in the user's settings, any position that hasn't been filled after 60 days, will be closed.

DCAAmountPercentage1

For Signal Providers: To accept DCA settings, the user has to have the Accept DCA Parameters From the Buy Signal? Checked in the provider's options.

DCATargetPercentage1

For Signal Providers: To accept DCA settings, the user has to have the Accept DCA Parameters From the Entry Signal? Checked in the provider's options.

Example explanation:
In this example, we are going to open a position with two DCAs configured to buy back 100% of the position upon reaching the values of 3% and 5%. We also add a TP in the syntax.

DCATargetPrice1

DCAPriority

Signals Type: entry

*For Copytraders (this parameter is not available for Signal Providers)

percentage|price (default percentage) 

The system works in percentage, (as default) meaning when you use the above parameter 'DCATargetPrice1' the system calculates this price value in percentage from the entry price value.

When you apply DCAPriority as (DCAPriority = Price) it will now set your dca orders as an exact price instead of using the default percentage value. 

You can indicate your price including the 'DCATargetPrice1' parameter.
*The priority parameter will affect all the DCA targets.

Example explanation:
In this example we are going to continue with the logic of the previous one, we are going to program 2 DCAs and a TP. But this time we are going to prioritize the price in the DCAs.

Exchange

Signals Type: All of them

This field is mandatory, and it's used to specify for which exchange your signals are.

key

Signals Type: All of them

A mandatory parameter that is used to identify your provider.
You should not share your key. Never post it in a public place. Anyone with this key could send signals to your provider. You can get your key from your provider edit tab.

limitPrice

Market

Signals Type: entry, stop, start, disableMarket, enableMarket

You also can use pair. It specifies for which market the signal is.

MDXXXXX

orderType 

Signals Type: entry, exit

For buy signals, you can choose between limit, market, or stop-limit (or 'multi' for futures signals) 
Default is limit. The stop-limit order waits until the price in the buyStopPrice parameter has been reached and then places a buy limit order for the price specified in the limitPrice parameter.
To accept market buy orders, the user has to check the option: Allow buy market order (your price deviation won't have an effect)

For sell signals, can be market or limit. Limit orders remove the current unachieved take profits targets from the user and place a new one, for the remaining amount at the suggested price in the signal.

orderType = multi

Signals Type: entry

In a futures exchange, this will open a position with two orders, one long and one short.
The first side to fill will be used, any additional parameters (take profits/dcas/reduce/stop loss/trailing stop) will be adapted to the winning side.

Example explanation:
In this example we are going to continue with the logic of the previous one, we are going to program 2 DCAs and a TP. But this time we are going to prioritize the price in the DCAs.

to note:

• entry side needs to be long: "side":"long"
• orderType_long/orderType_short, cannot be market

If then the "short" wins, the position will be flipped but by default, and handled as a long one.
For copy trading, once the order is filled, a limit order will be created with limitPrice from the winning order.

panicBase

Signals Type: panicSell

Parameter exclusive from panicSell signals, if present, it will panic sell only positions with this coin as the base. Take into consideration that the symbols (pair, market), in Binance follow this name convention: BASEQUOTE, example: QTUMBTC (QTUM would be the base)

panicQuote

Signals Type: panicSell

Parameter exclusive from panicSell signals, if present, it will panic sell only positions with this coin as the quote. Take into consideration that the symbols (pair, market), in Binance follow this name convention: BASEQUOTE, example: QTUMBTC (BTC would be the quote)

positionSizePercentage

Signals Type: entry

The position size of your investment in percentage.

For Copytraders or Profit-Sharing services: The percentage is from the configured value in the allocated balance setting. It has to be a value between 1 and 100. As always if the resulting position size is below the minimum allowed by the exchange, it will fail.

For Signal Provider services: it is important not to include this parameter or positionSize in your syntax. You must enter your position size into the 'settings' section of your service profile page.
This is because if you do include positionSize into your syntax, it will affect the entry size of your connected followers.

positionSizeQuote

Signals Type: entry

The coin for the position size value. If none is used, the quote coin from your pair will be used
(from XRPBTC, it would be BTC)

postOnly

Signals Type: entry
examples: "postOnly":"true",

The order will be sent to the exchange as post-only, which means that it will ensure a Maker rebate. If for any reason the order would be executed against any resting order, it will be canceled instead. 

For this reason, the post-only option is only for Limit Order, If you send a buy limit order with a price higher than the current market price, it would cancel as it would be filled automatically. not allowing a maker rebate. This option is really helpful to control the fees that you pay to the exchange.

price

Signals Type: entry, exit

Your suggested base price for calculating the limit price. If you don't use any price, the system will use the current market price (when the signal arrived).

For Signal Providers:This parameter is conditioned by the Buy/Sell Price Deviation setting, which is configured by the user and can be positive or negative. Whatever setting the user has will be applied to the price, resulting in the limit price. If you don't want the price to be conditioned by the user's setting, then you can use the limitPrice parameter.

reduceOrderType

Signals Type: update

Options for orderType: limit (default), market

reduceTargetPercentage

Signals Type: update

This is the target price for the limit order, the target price is calculated from the average entry price.

key=xxxxxxxxxxxxxxxxxxxx
pair=BTCUSDT‌‌

type=entry‌‌
exchange=binance‌

exchangeAccountType=futures

side=long‌‌

orderType=market‌‌

leverage=25‌

stopLossPercentage=-5‌

takeProfitPercentage1=10‌

takeProfitAmountPercentage1=100

signalId=xxxxx01

key=xxxxxxxxxxxxxxxxxxxx
pair=BTCUSDT
type=exit

exchange=binance‌

exchangeAccountType=futures

orderType=market‌‌

signalId=xxxxx01