WebSocket vs REST APIs on Crypto Exchanges: What's the Difference
If you are wiring a strategy up to an exchange, one of the first technical forks you hit is WebSocket vs REST APIs on a crypto exchange. Both let your code talk...
A post-only order is a limit order that refuses to execute if it would take liquidity, so it always pays maker fees. Learn how the post-only flag works, why it matters in automated trading, and how to use it safely in a webhook-driven setup.
If you automate crypto trades, fees are a quiet cost that adds up every time your strategy fires. A post-only order is one of the simplest tools for keeping that cost down. It is a limit order with one extra rule: if the order would immediately match against a resting order and take liquidity, the exchange cancels it instead of filling it. That single rule guarantees the order stays on the maker side of the book, which is where the cheaper fee tier lives.
This guide explains what a post-only order does, why the flag exists, what happens when it collides with the market, and how to use it well inside an automated, webhook-driven trading setup. It assumes you already generate signals somewhere and want your orders to reach an exchange without paying more than they need to.
Every order you send either adds liquidity to the order book or removes it. A resting limit order that sits and waits for someone else to trade against it adds liquidity. An order that fills immediately against what is already there removes it. The exchange charges you differently depending on which side you land on.
A post-only order forces the first outcome. You submit a limit order with the post-only flag set, and the exchange checks one thing before accepting it: would this order match right now? If yes, it rejects or cancels the order outright, so nothing executes. If no, the order is placed on the book as a normal resting limit order, waiting to be filled later.
The practical effect is a promise: this order will never cross the spread and pay the taker fee. It either rests as a maker order or it does not exist.
Exchanges want deep, liquid order books, so they reward the traders who provide that depth. Traders who post resting orders are makers; traders who consume those orders are takers. Maker fees are almost always lower than taker fees, and on some venues makers even receive a small rebate.
Over a handful of manual trades, the gap looks trivial. Over an automated strategy that places dozens or hundreds of orders, it compounds into a real line item. If your logic can tolerate resting on the book instead of demanding an immediate fill, the post-only flag locks you onto the cheaper side every time. For a fuller breakdown, see our guide on maker vs taker fees and what they mean for automated orders.
This is the part that trips people up in automation. Suppose you place a post-only buy limit at a price that is already at or above the current best ask. A normal limit order would fill instantly as a taker. A post-only order cannot do that, so the exchange steps in.
Exactly what happens next depends on the venue. Some exchanges reject the order with an error, some accept it and immediately cancel it, and a few slide the price to just behind the best quote so it can rest without crossing. The common thread is that no fill happens at the crossing price. Your automation has to treat a post-only rejection as a normal, expected outcome rather than a failure, because it happens whenever your target price has already been reached.
Manual traders can watch the book and adjust. An automated system fires on a signal and walks away, so the behavior of each order type has to be understood in advance. Post-only orders change the shape of your execution in three ways.
First, they make cost predictable. You know every filled order landed on the maker side, so your fee assumptions hold no matter how many times the strategy triggers. Second, they introduce the possibility of no fill. A post-only order that would have crossed simply does not execute, so your position may not change when you expected it to. Third, they interact with your time-in-force choice: a post-only order still needs a rule for how long it rests, which is where settings like GTC come in. Our guide on time-in-force options such as GTC, IOC, and FOK covers how those interact.
Because of the no-fill case, post-only is a poor fit for signals that must be executed right now at any cost, such as a stop that needs to close a position immediately. For those, a market or aggressive limit order is the honest choice, even at the taker fee. Post-only shines when entry price matters more than entry speed.
In a webhook-driven relay, your TradingView alert or automation platform sends a signal describing the order, and a relay submits it to the exchange through your API keys. To use post-only, your alert payload needs to carry the intent: a limit order type, a target price, and the post-only flag. The relay then maps those fields to whatever the exchange's API calls the flag, since the naming differs across venues.
SignalToExchange is a non-custodial relay for exactly this kind of setup. Your funds never leave your exchange, and you connect trade-only API keys with no withdrawal access, so the relay can place and cancel orders but never move your balance. Post-only is just one more field it passes through: you decide the order logic, and the infrastructure carries it to the exchange reliably. Because a post-only order can be rejected on purpose, a good relay reports that rejection back clearly so your system knows the order did not rest. For a refresher on the underlying mechanics, our explainer on how crypto exchange order books work is a useful companion.
Post-only is not free of downsides, and being honest about them keeps your automation predictable. The main cost is missed fills: if the market moves through your price before your order rests, you get nothing, so a strategy that insists on post-only entries can sit on the sidelines while price runs away. It also adds code complexity, because your system has to detect and handle rejections instead of assuming every order fills. And post-only does not reduce trading risk in any way; it only changes which fee tier you land on and whether a fill happens. It is a cost-control tool, not a safety feature.
Not quite. A post-only order is a limit order with an added constraint. A normal limit order can still fill immediately as a taker if its price crosses the book. A post-only order refuses to do that and will be rejected or canceled instead, so it only ever rests as a maker order. For the broader distinction between order types, see our guide on market vs limit orders in automated trading.
No. It guarantees the opposite kind of certainty: your order will never take liquidity or pay the taker fee. Whether it fills depends on the market trading against it while it rests. If price never returns to your level, the order simply stays open or expires unfilled.
Most major crypto exchanges support a post-only flag, but the name and the exact rejection behavior vary โ some reject, some cancel, some reprice. Always confirm how your venue handles a crossing post-only order before relying on it in automation.
Only where it fits. Post-only lowers your fee tier but adds the chance of no fill, so it suits price-sensitive entries more than time-sensitive exits. Match the order type to what the signal actually needs.
Post-only is a small flag with an outsized effect on automated trading cost: it keeps every filled order on the maker side and makes your fee assumptions hold. Used deliberately, alongside a clear plan for rejections and time-in-force, it is a straightforward way to keep execution lean. SignalToExchange routes your signals to your exchange over trade-only keys, so you keep custody of your funds and control of your logic. Request access or start your free trial to connect your first strategy.
Automated trading involves risk. SignalToExchange is execution infrastructure and does not provide financial advice, trading signals, or guarantees of any kind.
Non-custodial execution. Trade-only API keys. Independent infrastructure built for reliability.
Request Early AccessTrade-only API key enforcement. No withdrawal permissions. No custody.