Tradovate API/Webhook Limit Order Price Slippage

You set your strategy to close at 4100. The alert fires, the message plainly reads 4100, and yet the working order shows up at 4100.50. Nothing crossed the market, nothing filled at a bad price, the number just changed somewhere between your alert and the order book. That's maddening, and it's the kind of thing people call “slippage” while quietly knowing it isn't quite that.

Here's the short version: futures prices don't live on a smooth number line. They exist only on a fixed grid of ticks. If the price your strategy hands off isn't an exact multiple of that grid, something has to round it, and the direction it rounds is rarely the one you had in your head. Fix where the price gets aligned, and make sure the limit isn't sitting on the wrong side of the market, and the phantom half-point goes away.

This guide walks through why the price moves, how to pin down which of the three usual causes you're hitting, and exactly what to change so your limits land on the number you meant.

What "slippage" actually means here

It's worth separating two very different things, because the fix depends on which one you have.

Real slippage happens on a market order: you accept whatever the book gives you, and in a fast or thin market that's a few ticks worse than the last print. There's no price to protect, so there's nothing to debug, that's the trade you asked for.

What you're seeing is different. A limit order carries a specific price, and that price is getting transformed before it rests on the book. The number in your alert and the number on the working order don't match. That's not the market moving against you; that's your price being reshaped in transit. Good news: reshaped prices are predictable, and predictable means fixable.

Why the price moves off your target

Three mechanisms cause almost every case. They can stack, so it's worth knowing all three even if only one is biting you today.

1. The price isn't on the tick grid

Every contract has a fixed minimum increment. Send a price that falls between two legal ticks and it gets rounded to the nearest one. That's not a bug, a price off the grid simply can't exist on the exchange, so it has to snap somewhere.

The trouble is that different contracts snap at different sizes, and it's easy to assume the wrong one:

Say your logic computes a gold exit at 2050.05. There's no such price, GC moves in dimes, so it rounds to 2050.00 or 2050.10, and now your “5 cents better” exit is a dime off. Confirm the current increment on the exchange's contract spec page before you trust these numbers; the exchange can adjust a tick size, and micro contracts don't always match their full-size sibling.

2. Floating-point math nudges you across a tick

This is the sneaky one, and it's usually behind the classic “sent 4100, got 4100.50” complaint. ES trades in quarters, so both 4100.00 and 4100.50 are perfectly legal. The price didn't round because it was off-grid, it rounded because the value your strategy actually computed wasn't the clean 4100 you saw in the alert text.

Strategies rarely hard-code an exit. They calculate it: an entry minus an offset, a moving-average value, a percentage of a range. Do that in floating-point and you get numbers like 4100.4999999 or 4100.3700001. Round that to the nearest quarter and you can easily land a half-point away from where the round number in your alert made it look like you'd land. The alert message and the price field can even disagree, because one is display text and the other is the value being sent.

3. The limit is already through the market

This one is real slippage wearing a limit-order costume. A buy limit priced above the current ask, or a sell limit priced below the current bid, is “marketable”, it can fill immediately at the best available price instead of resting. So if your strategy computes a limit on the wrong side of the market (a common sign flip: subtracting an offset when you meant to add it), the order crosses the spread and fills at a price that looks nothing like your number.

The tell: rounding errors put you a tick or two off, always in a rounding-shaped way. A marketable limit puts you wherever the book was, which can be several ticks and always on the side that costs you. If the gap is bigger than one tick and consistently against you, suspect the side of the book, not the grid.

How to fix it, step by step

If you're routing through a webhook or bridge

When a TradingView alert drives the order through a bridge, there's an extra handoff where the price can drift. The alert fires with a value, the bridge maps that value into an order payload, and the payload is what reaches the broker. Two things keep it honest.

First, make the strategy the single source of truth for the price, round to the tick inside your Pine logic and pass that exact, pre-rounded number into the alert, rather than sending a raw close and hoping the downstream rounds it the way you'd want. Second, confirm the field the bridge reads is the price field, not a label.

Tired of hand-rounding prices and chasing where a half-tick crept in? PickMyTrade routes your TradingView alerts to Tradovate and handles the tick alignment for you, so the limit that leaves your strategy is the limit that lands on the book.

How to keep it from coming back

Once it's fixed, a few habits stop it recurring:

• Round in the strategy, always. Never send a raw computed price and let something downstream decide the tick.
• Log raw and rounded. Keep both values in your logs so a stray tick is a two-second diff, not a mystery.
• Test in sim first. Fire the alert into a simulated account and eyeball the working price before you trust it with real size.
• Work in ticks, not points, for offsets. Decide up front which unit your offsets are in and convert once, in one place.
• Watch bracket legs too. Stop and target prices round the same way; if your protective legs land off, the same rounding fix applies. If those legs fail to attach at all, that's a different issue, see our guide on Tradovate API bracket (OSO/OCO) orders failing.