Batch Signals: Five Trades in One Webhook

A batch signal lets a single webhook request carry up to five independent signals, each with its own ticker, action, quantity, and order type. Where a normal webhook body is a JSON object, a batch is a root-level JSON array where each element is treated as its own signal, processed separately from the others. This opens up workflows that a single-signal alert cannot handle: entering two instruments simultaneously, laddering limit orders across price levels, or closing one position while opening another.

The mechanics are straightforward but the failure mode is absolute. If any item in the array fails validation, the entire request is rejected and no trades are created for any item. Understanding that all-or-nothing behavior before you send a batch to a live strategy will save you from silent misses during fast-moving markets.

This article covers the two payload shapes, the toggle that separates them, three practical use cases, validation rules, the five-item hard cap, and what to check before you point a live alert at a batch-enabled strategy.

What a Batch Signal Actually Is

Object vs. array payload

A normal webhook body is a single JSON object. A batch is a root-level JSON array containing multiple signal objects. The structure looks like this:

[ { "ticker": "MES", "action": "buy", "quantity": 1 }, { "ticker": "MNQ", "action": "buy", "quantity": 1 } ]

Each item in the array is treated as its own independent signal, not a compound instruction. The platform reads the array, splits it into individual signals, and routes each one through the same validation and execution pipeline a standalone signal uses. Every field available in a single-signal payload, including ticker, action, quantity, orderType, limitPrice, stopLoss, takeProfit, and timeInForce, is valid inside each array item.

The setting that unlocks arrays

Batch processing is gated behind a per-strategy toggle called Allow batch signals. Without it enabled, any array payload is rejected with the error batch-signals-not-enabled and no trades are created for any item in the array. The evaluation happens before the payload is read: if the toggle is off, the request is rejected in full before any individual item is examined.

The default state of this toggle depends on when the strategy was created. Strategies that existed before the batch signals feature was introduced have the toggle off by default, so they must opt in deliberately before any array payload will be accepted. Strategies created after the feature launched have it on by default.

One edge case worth noting: a JSON array that contains only a single object is still treated as a batch request. It requires the toggle to be on, and the Signals page displays it as a single signal rather than an expandable batch. There is no practical benefit to wrapping a lone signal in an array; use the plain object shape instead.

Three Situations That Want a Batch

Entering two contracts at once

The most direct use case is entering positions in two different instruments from a single alert. Each item in the array carries its own ticker and quantity, so the two entries can differ in size, order type, or any other per-signal field. A single TradingView alert fires, one webhook request is sent, and both entries are submitted without you having to maintain two separate alerts or coordinate their timing.

Closing one position, opening another

One array item can carry action: "sell" to exit an existing position while a second item carries action: "buy" to open a new one. Before relying on this pattern, read the race conditions documentation carefully. Items in a batch are not guaranteed to execute sequentially, which means an exit in item one is not guaranteed to fill before item two's entry is submitted. If exit-before-entry sequencing is a hard requirement, the single-signal flow handles it by waiting for the exit to fill before placing the entry.

Laddering limit orders on one ticker

The same ticker may appear more than once in a single batch. This is what makes laddering several limit orders from one alert possible. Each repeated-ticker item can carry a different limitPrice, quantity, or orderType, spreading entries across multiple price levels from one alert firing. For example, three items each with the same ticker but different limitPrice values will produce three separate limit orders, all submitted from a single webhook request.

The Two Payload Shapes

Single-signal object (always works)

A JSON object at the root is accepted by any strategy regardless of the batch signals toggle. The minimum required fields are ticker and action; all other fields are optional. This shape should remain the default when you only need one trade per alert. Adding an array wrapper for a single signal buys nothing except an extra requirement on the toggle.

Multi-signal array (requires setting)

A JSON array at the root triggers batch processing. Each element must itself be a valid signal object with at least ticker and action. The array may hold between one and five elements; an array with more than five elements is rejected with too-many-payload-items and no trades are created for any item. Fields like orderType, limitPrice, quantity, stopLoss, and takeProfit can differ between array items, giving full per-signal control over every order in the batch.

Validation Is All or Nothing

One bad item kills the whole batch

If any single item in the array fails validation, the entire request is rejected and no trades are created for any item in it. There is no partial execution. A five-item batch where item three is malformed produces zero trades, not four. This is the most important behavioral difference between batches and back-to-back individual signals: a sequence of five separate requests would succeed or fail independently per request; a batch fails as a unit.

Common rejection reasons

• batch-signals-not-enabled: The strategy's Allow batch signals toggle is off. The entire array is rejected before any item is read.
• too-many-payload-items: The array contains more than five elements. No trades are created for any item.
• Missing ticker or action: Standard single-signal validation applies to each item individually. A missing required field on any item rejects the whole batch.
• Unrecognised action or invalid orderType: Any item with a field value the platform does not recognise will fail and bring the entire batch with it.

The Five-Item Limit and Edge Cases

Why five matters

The hard cap is five signals per batch request. Any array with six or more items is rejected in full with too-many-payload-items. If a use case requires more than five simultaneous signals, the only option is to send multiple separate webhook requests. That path reintroduces the race conditions that batching was partly designed to avoid, so it is worth designing signal logic to stay within the five-item limit where possible.

A list of one is still a batch

An array containing a single object is treated as a batch request, not as a shorthand for the single-object syntax. It requires Allow batch signals to be enabled, and the Signals page displays it as one signal rather than an expandable batch list. The plain object shape is always preferable for single signals: it works without the toggle, displays identically on the Signals page, and eliminates one potential rejection path.

What a Batch Looks Like After It Lands

Signals page display

A multi-item batch appears as an expandable entry on the Signals page, letting you inspect each constituent signal individually. This visibility is one of the practical advantages of batching: instead of hunting through multiple individual signal entries, all items from one alert are grouped under a single expandable row. A single-item array, by contrast, appears as a regular signal with no expansion, reinforcing why wrapping a lone signal in an array adds no observability benefit.

Timing and latency implications

Each item in a batch still goes through the planning and execution phases independently, so total processing time grows with the number of items. Including a time field in each item using an ISO-8601 timestamp allows per-signal latency tracking between when the alert fired and when each order was placed. Race conditions apply within a batch in the same way they apply to back-to-back individual signals: do not assume item two waits for item one to fill before being submitted to the broker.

What a Batch Does Not Give You

No guaranteed execution order

Items in a batch are not guaranteed to execute sequentially. An exit in item one is not guaranteed to fill before an entry in item two is submitted. For exit-then-enter workflows that require sequencing, the single-signal approach handles it correctly: send one signal with the appropriate action and the platform ensures the exit fills before the entry is placed. Relying on array order for sequencing is a design risk that the platform documentation explicitly flags.

No atomic rollback

If item three of a five-item batch is accepted by the platform but later rejected by the broker, the other four items are not automatically canceled. Failed or rejected orders are never retried; the platform does not roll back other items in the same batch when one broker rejection occurs. Monitor the Signals page and your broker's order log after sending batches, particularly when you are running the feature for the first time on a live account.

Before You Switch a Live Alert Over

Test with a paper strategy first

Send the batch payload with test set to true on each item to verify that every item is parsed and accepted without routing live orders to the broker. Confirm that the Signals page shows the expected number of signals and that each item reflects the correct ticker, action, and order details before enabling the alert in production. TradersPost paper trading runs the full batch flow, including validation, signal logging, and execution planning, without touching a live account, making it the right environment for a first send.

Check the toggle on existing strategies

Strategies created before the batch signals feature was introduced have the toggle off. Verify the Allow batch signals setting is enabled before sending any array payload to an existing strategy. If you are converting a TradingView alert from a single-object payload to an array, update the alert message in TradingView at the same time you enable the toggle, not before. Sending an array to a strategy where the toggle is still off results in a full rejection with no trades created.

Validate every item before sending

Because one invalid item rejects the entire batch, run each signal object through the same checks you would for a standalone signal before wrapping them in an array. Pay particular attention to ticker spelling for futures contracts. Continuous symbols like NQ1! are mapped to the front-month contract on a rollover schedule that may differ from TradingView's, so explicit contract symbols such as MNQU2025 are recommended over continuous symbols.

Bottom line before going live:

• Enable Allow batch signals on the strategy before sending any array payload.
• Set test: true on every item in the array and confirm the Signals page output matches expectations.
• Use explicit futures contract symbols rather than continuous symbols in batch payloads.
• Update the TradingView alert message and the strategy toggle at the same time when converting an existing alert.
• Remember that one bad item in any position rejects every item; validate each object before wrapping it in the array.

Conclusion

Batch signals solve a real problem: coordinating multiple orders that belong to the same moment without splitting them across separate alerts. The five-item array format gives you enough headroom to enter correlated instruments, ladder limit orders, or pair an exit with an entry, all from one webhook request. The trade-off is that validation is binary, execution order is not guaranteed, and broker rejections do not roll back the rest of the batch.

The toggle, the payload shape, and the all-or-nothing validation rule are the three things that trip people up. Get those right in a paper environment first, confirm the Signals page reflects what you expect, and then cut the alert over to live. That sequence costs five minutes and prevents the kind of silent failure that only shows up in a broker statement the next morning.

Frequently Asked Questions

Does every item in a batch need the same ticker?

No. Each item can specify a different ticker, making it possible to enter or exit multiple instruments from one alert. The same ticker can also appear more than once in the same batch, which is the mechanism behind laddering limit orders at different price levels.

What happens if I send six signals in one array?

The request is rejected with too-many-payload-items and no trades are created for any of the six items. The maximum is five signals per batch request. Split larger sets across multiple separate webhook requests if needed, keeping the race conditions between requests in mind.

Can I mix order types within a batch?

Yes. Each item is an independent signal object, so one item can use orderType: "limit" with a limitPrice while another uses orderType: "market". Fields like stopLoss, takeProfit, quantity, and timeInForce can all differ between items in the same array.

Will a batch wait for item one to fill before placing item two?

No. Items are not guaranteed to execute sequentially; the platform does not wait for a fill on one item before submitting the next. If you need an exit to fully fill before a new entry is placed, use a single signal with the appropriate action so the platform handles the sequencing internally.

Does setting test to true in one item apply to the whole batch?

No. The test field is per-item; set it on each object individually if you want the entire batch treated as a test. Omitting test from even one item while others have it set to true could result in a mix of test and live signals in the same batch, with the live item routing an actual order to your broker.