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...
GTC, IOC, and FOK are the time-in-force order types that decide whether an automated order rests, fills instantly, or cancels. Here is how each behaves and when to use it.
If you automate crypto trades, one small setting quietly decides whether your order rests on the book, fills instantly, or disappears the moment it is sent. That setting is time-in-force. Understanding the common time-in-force order types — GTC, IOC, and FOK — is one of the fastest ways to make automated execution behave the way you actually intend. A signal that fires correctly can still produce the wrong result if the order carries the wrong time-in-force instruction.
This guide explains what time-in-force means, walks through GTC, IOC, and FOK one at a time, shows how each behaves inside an automated setup, and gives you a simple framework for choosing the right one for each strategy.
Time-in-force is an instruction attached to an order that tells the exchange how long the order should stay active before it is either filled or cancelled. It does not change the price or the size of your trade. It changes the order's lifespan and how aggressively the exchange tries to match it.
When you place an order manually, you can watch the book and cancel by hand. Automation removes that human step. Your system sends the order and moves on, so the time-in-force value becomes the rule that governs what happens next without you watching. Choosing it deliberately is what separates predictable execution from surprises.
Time-in-force interacts closely with order type. If you are still deciding between resting and immediate orders, our guide on market vs limit orders in automated trading pairs directly with this one, because time-in-force is most meaningful on limit orders.
GTC, or Good-Til-Cancelled, keeps an order active until it fully fills or you explicitly cancel it. It is the default on many exchanges and the most familiar behavior for resting limit orders. You set a price, the order joins the book, and it waits there — for minutes, hours, or days — until the market reaches it.
For automated trading, GTC is useful when you want to sit on the book at a specific level and are willing to wait. A strategy that places a bid below the current price and expects a pullback is a natural fit. The trade-off is that a GTC order can linger far longer than you expect. If your strategy fires again while an old GTC order is still resting, you can end up with stacked or conflicting orders unless your system tracks and cleans them up.
The practical rule with GTC in automation: if you use it, you must also manage cancellation. Left unattended, resting orders accumulate. Pair GTC with logic that cancels stale orders before placing new ones, or you may fill an order your strategy no longer wants.
IOC, or Immediate-Or-Cancel, tells the exchange to fill as much of the order as it can right now, at your specified price or better, and cancel whatever cannot fill immediately. Partial fills are allowed. If only part of your size is available at your price, you get that part and the remainder is discarded.
IOC shines in automation when you want to take liquidity without leaving a resting order behind. Say your signal wants to enter a position at or near the current price but you do not want a leftover order sitting on the book if the full size is not available. IOC gives you whatever the market offers at that moment and cleanly cancels the rest. Because it never rests, it avoids the stacking problem that GTC can create.
The trade-off is fill uncertainty. You might get a partial fill or, if the book has moved, no fill at all. Your automation needs to check the actual filled quantity in the exchange response and react accordingly rather than assuming the full size executed.
FOK, or Fill-Or-Kill, is the strictest of the three. It demands that the entire order fill immediately and completely at your price or better. If the full quantity cannot be filled in one shot, the whole order is cancelled — no partial fills, nothing left resting.
FOK is the right choice when a partial fill would be worse than no fill. If your strategy depends on entering a full position size or none at all — for example, a setup where a half-filled position breaks your risk assumptions — FOK protects you from being left with an awkward partial. In automation, this all-or-nothing behavior makes downstream logic simpler: either the position exists in full, or it does not exist at all.
The cost is that FOK fails more often than IOC in thin markets. Demanding a complete immediate fill is a high bar when liquidity is fragmented. To understand why a large FOK order may be hard to fill at a single price, it helps to know how crypto exchange order books work.
In manual trading you absorb an unexpected outcome by adjusting on the fly. In automation, the time-in-force value is a contract your code has to honor. A rejected FOK order, a partial IOC fill, or a forgotten GTC order all become events your system must detect and handle.
This is why time-in-force and error handling go together. Whatever you choose, your automation should read the exchange acknowledgment, confirm the filled quantity, and decide what to do next. Our guide on handling failed and rejected orders in a trading bot covers the response-parsing patterns that make this reliable. Time-in-force also shapes slippage: aggressive immediate orders take liquidity and can move through the book, so pairing this with reducing slippage in automated crypto trading is worth your time.
At SignalToExchange, orders are submitted with an explicit time-in-force so behavior is deterministic rather than left to an exchange default. Because the platform is non-custodial and connects through trade-only API keys, it can place and cancel orders on your behalf without ever having withdrawal access to your funds. You control the logic; the relay handles submission exactly as instructed.
There is no single best option — the right choice depends on what your strategy needs from a fill. A few practical guidelines:
Both cancel any unfilled portion immediately, but IOC allows partial fills while FOK does not. IOC takes whatever it can get right now and discards the rest; FOK requires the entire quantity to fill at once or cancels everything.
On most crypto exchanges, GTC is the default for limit orders. If you do not specify a time-in-force in your automated order, the exchange will typically treat it as GTC and let it rest until filled or cancelled — which is why setting it explicitly matters.
Time-in-force is most meaningful for limit orders. Market orders fill against available liquidity right away, so exchanges often handle them as immediate-style orders regardless of the flag. Always check your exchange's documentation for exact behavior.
Indirectly. IOC and FOK limit how long an aggressive order lives, which can prevent it from chasing a moving market, while a resting GTC limit order controls the price you accept. Neither eliminates slippage, but choosing deliberately helps you manage it.
Time-in-force is a small field with outsized influence on how your automated orders behave. GTC rests and waits, IOC takes what it can and cancels the rest, and FOK insists on all-or-nothing. Match the instruction to what your strategy actually needs, always confirm the fill, and clean up resting orders so nothing lingers. Getting this right makes automated execution predictable instead of surprising. To see how deterministic, explicitly-controlled order submission works on non-custodial, trade-only infrastructure, request access or start your free trial with SignalToExchange.
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.