Price does not move on its own. It moves because someone crosses the spread — a taker who is willing to pay the ask to get filled now, or hit the bid to get out now. Order flow imbalance (OFI) is the measurement of that impatience: how much aggressive buying pressure is hitting the book versus aggressive selling pressure over a given window. When buyers are the ones reaching across, the book gets eaten from the bid side up and price drifts higher. When sellers are reaching, it drifts lower. OFI quantifies the side and the size of that pressure before the candle finishes printing.
OFI from first principles
Every trade has a maker and a taker. The maker posted a resting limit order; the taker removed it by crossing the spread. The taker is the aggressor — they expressed urgency, and urgency is information. A simple, honest definition of OFI is the net of taker-initiated buy volume minus taker-initiated sell volume over a window, often combined with changes in resting depth at the best bid and ask. Positive OFI means net aggressive buying; negative means net aggressive selling. The intuition is mechanical, not statistical: to lift the offer you must consume liquidity, and consuming liquidity moves the price level. OFI captures that consumption as it happens.
This is why OFI is a leading quantity on seconds-to-minutes horizons rather than a lagging one. A moving average tells you where price has been. OFI tells you who is currently doing the work of moving it. On crypto perpetuals — where takers chase liquidations, hedge funding, and react to spot — that aggressive flow often shows up in the tape a beat before the mid-price fully reprices.
Why aggressive flow front-runs price
- Liquidity is finite at each level. Sustained one-sided aggression walks the book and forces the mid to follow.
- Aggressors reveal conviction. A trader paying the spread repeatedly is telling you they expect to be right soon, not eventually.
- Imbalance clusters. Flow is autocorrelated over short windows — a burst of aggressive buying tends to be followed by more of it before it exhausts.
- It is orthogonal to price-only signals. Two assets can have identical recent returns but opposite OFI, and the OFI side is usually the one that resolves the next move.
How OFI is addressed in QUANT_API
QUANT_API exposes order flow imbalance as two real signals: flow.ofi and flow.ofi_extended. The extended variant incorporates a richer view of depth changes across multiple book levels, so it responds to pressure that has not yet touched the very top of book. Both are addressed with the same scheme used across the whole catalog: category.signal@window[:transform]. So flow.ofi@30s is order flow imbalance computed over a 30-second window, and flow.ofi_extended@5m is the extended version over five minutes.
Windows run from 1s through 24h — 1s 5s 15s 30s 1m 5m 15m 30m 45m 1h 2h 4h 12h 24h — which lets you watch the same imbalance across the time scales where it actually lives. A 5-second OFI burst and a 30-minute OFI trend are different objects, and you address them explicitly rather than reconstructing them yourself.
Raw OFI is hard to threshold because its scale shifts with volatility and volume regime. That is what the zscore transform is for: flow.ofi@1m:zscore normalises the one-minute imbalance against its own recent distribution, so a value of, say, +2 means meaningfully one-sided for this asset right now rather than relative to some fixed constant. Other transforms — delta for the change in imbalance, pctrank for its percentile, ewma for a smoothed version — are available on the same address. Browse the full set in the catalog.
The leak-free point: OFI is only honest if every value is computed from the trade tape and book exactly as it stood at the decision time. Exchanges sometimes revise or backfill trades; if a backtest uses that revised tape, your OFI silently 'knows' things that were not knowable yet, and the result is inflated. QUANT_API computes every value strictly from data with ts <= as_of — live or historical — so a backtest reflects exactly what was on the tape at decision time, not what was corrected later.
This is the entire reason point-in-time matters for a flow signal. Look-ahead from a revised tape is one of the most common and least visible ways an order flow strategy backtests beautifully and then disappoints live. Because the same engine resolves both GET /v1/features/live and POST /v1/features/historical, the OFI you trade on and the OFI you researched against are produced the same way — there is no train/serve gap to introduce a leak.
# Resolve order flow imbalance for BTC and ETH right now, # 1-minute window plus a z-scored 30-second burst and the extended variant. curl -s https://api.quant-api.dev/v1/features/live \ -H "Authorization: Bearer fk_live_<secret>" \ -G \ --data-urlencode "assets=BTC,ETH" \ --data-urlencode "features=flow.ofi@1m,flow.ofi@30s:zscore,flow.ofi_extended@5m"
To research it instead of trade it, post your own timestamps to POST /v1/features/historical and you get a point-in-time matrix of the same OFI addresses — each row computed as of that row's timestamp. That is the input you want feeding POST /v1/backtest. The full request shapes are in the docs, and related signals like flow.vpin and positioning.taker_ratio extend the same aggressive-flow picture if you want to combine views — see other guides.
OFI is one of the highest-signal places to start because it is mechanical, fast, and easy to reason about: someone is paying to move price, and you can see which side. Wire flow.ofi and flow.ofi_extended across a couple of windows, normalise with zscore, and test it point-in-time. Compare plan limits on pricing when you are ready to widen the asset and window coverage.