userFillsByTime | Hyperliquid Info API
Info API
userFillsByTime | Hyperliquid Info API
Hyperliquid userFillsByTime: fetch a user’s trade fills within a time window for P&L recaps and tax ledger reconstruction.
POST
userFillsByTime | Hyperliquid Info API
Credit Cost
1 per call
Processing
Realtime
type: "userFillsByTime" is used to fetch a user’s trade fills within a time window for P&L recaps and tax ledger reconstruction.
- Wire-equal to
POST api.hyperliquid.xyz/infowith{"type": "userFillsByTime", "user": "...", "startTime": ...}. - Each response contains at most 2,000 fills; widen the window in chunks or page by advancing
startTimeif you need more. - GoldRush serves this
typefrom a dedicated HyperCore historical store, so windows older than upstream Hyperliquid’s 10,000-fill retention are still fulfilled. - For real-time push instead of windowed polling, subscribe to
walletTxsand readHypercoreFillTransactionevents. - Use
userFills(noTimesuffix) when you only need the most recent N fills without specifying a window.
[startTime, endTime) window in milliseconds. Use this when you want fills since a specific moment - daily P&L recaps, post-deploy backfills, or rebuilding a tax ledger - rather than the most recent N fills.
User-keyed. The upstream Hyperliquid API caps each response at 2,000 fills; page by advancing startTime. NOT LIMITED TO THE 10,000 MOST RECENT FILLS. GoldRush serves this type from a dedicated HyperCore historical store so windows extending past the upstream retention limit are fulfilled from GoldRush data rather than truncated.
Endpoint
Request
Always
"userFillsByTime".The wallet address (lowercase 0x-prefixed hex).
Unix timestamp in milliseconds. Inclusive lower bound.
Unix timestamp in milliseconds. Inclusive upper bound. Defaults to current server time when omitted.
When
true, partial fills sharing the same timestamp are consolidated into one row. Default false.Example
Response
An array of fill objects ordered bytime.
Field descriptions
All numeric fields (
px, sz, startPosition, closedPnl, fee, builderFee) are returned as decimal strings, preserving upstream precision. Do not parse them as floats - keep them as strings or use a fixed-precision decimal type.Asset symbol - e.g.
"BTC", "ETH" for perps; spot pairs use the @N form (e.g. "@107").Fill execution price.
Fill size.
"B" for buy/long, "A" for ask/short.Unix timestamp in milliseconds when the fill executed.
Signed position size on the same coin immediately before this fill.
Human-readable direction label - e.g.
"Open Long", "Close Short", "Buy", "Sell".Realized PnL in USDC attributable to this fill (zero when the fill opens or extends a position).
L1 transaction hash that included this fill.
Parent order ID.
Unique trade ID.
true when the fill came from the taker side of the order, false when it was the maker side.Trading fee paid for this fill, denominated in
feeToken.Symbol the fee was paid in - typically
"USDC".Optional. Builder fee paid for this fill if the order routed through a builder code.
Optional TWAP order ID if this fill is a slice of a TWAP order.
Optional client order ID if one was set at order placement.
Related endpoints
userTwapSliceFillsByTime
fetch a user’s TWAP slice fills within a time window for execution-quality reconciliation on algorithmic…
builderFillsByTime
fetch a builder’s attributed trade fills within a time window for revenue attribution and fee accounting.
userFills
fetch a user’s most recent trade fills without specifying a time window.
userTwapSliceFills
fetch a user’s most recent TWAP slice fills for execution-quality analytics on algorithmic orders.