> ## Documentation Index > Fetch the complete documentation index at: https://docs.0xarchive.io/llms.txt > Use this file to discover all available pages before exploring further. # Hyperliquid Fills Data API > Hyperliquid fills are per-trade rows with wallet attribution where returned, maker/taker fields, April 2023 coverage, plus TP/SL and order-lifecycle routes. On Hyperliquid, a fill is one matched execution: an order crosses the book, the venue records the price, size, side, and the wallets involved where reported. 0xArchive has no separate fills route because the Hyperliquid trades route is the fill-level surface. `/v1/hyperliquid/trades/{symbol}` returns fill-level rows with `user_address` where the venue reports it, with native trade coverage reaching back to April 2023; verify the selected symbol's exact window and gaps before relying on it. ```bash theme={"theme":"github-dark"} curl "https://api.0xarchive.io/v1/hyperliquid/trades/BTC?limit=1" \ -H "X-API-Key: $OXARCHIVE_API_KEY" ``` ```json theme={"theme":"github-dark"} { "success": true, "data": [ { "coin": "BTC", "side": "B", "price": "63743", "size": "0.0002", "timestamp": "2026-06-04T13:53:39.609Z", "trade_id": 397759113671327, "direction": "Open Long", "fee": "0.005507", "fee_token": "USDC", "start_position": "0.03919", "crossed": true, "user_address": "0x1f1fab9e5fc092f02cf833fd487b64703cbf536a", "tx_hash": "0xcf8038aff0c5753fd0f9043cf4049502051b00958bc894117348e402afc94f2a" } ], "meta": { "count": 1, "next_cursor": "1780581219809_333265093496905", "request_id": "8f3d2a6c-4b1e-4e9a-9c07-5d21f0a83b64" } } ``` Fill-level trade routes by venue family. Core perp route family. ## Why it matters The fill tape is the right starting point for execution research, but wallet and builder attribution are response data, not server-side trades filters. Pull a bounded venue, market, and time window, paginate with cursor, and filter rows client-side. Use the corresponding export schema for large market-wide studies. ## What A Fill Row Carries Each row is one execution with the context most fills APIs drop: | Field | What it tells you | | - | - | | `side` | `B` (buy) or `A` (sell) | | `crossed` | `true` if this wallet took liquidity (taker), `false` if it rested (maker) | | `fee` | Fee paid, including any builder fee; a negative value is a maker rebate | | `user_address` | The wallet behind the fill, where the venue reports it | | `direction` | Position effect, such as `Open Long` or `Close Short` | | `closed_pnl` | Realized PnL on this fill; `"0"` when the fill opened or added to a position | | `start_position` | Position size before this fill; `"0"` means flat | | `tx_hash` | The chain transaction that carried the execution | `maker_address`, `taker_address`, `order_id`, and `cloid` appear where applicable, so a fill can be joined back to the order that produced it. Prices, sizes, and fees are decimal strings. Recorded zeros are returned as `"0"`; a missing `fee`, `closed_pnl`, or `start_position` means the source did not record it, as on fills from March 22 to May 25, 2025. ## Fills Intent To Route Map | Fill question | Route | | - | - | | The fill tape for one symbol and window | `/v1/hyperliquid/trades/{symbol}` | | TP/SL triggers before and after they fire | `/v1/hyperliquid/orders/{symbol}/tpsl` | | The lifecycle around each fill: placed, partially filled, filled, canceled | `/v1/hyperliquid/orders/{symbol}/history` | | The resting orders those fills executed against | `/v1/hyperliquid/orderbook/{symbol}/l4/history` | These route families use the standard `{success, data, meta}` envelope. Cursor types and page-size rules remain route-specific; preserve `meta.next_cursor` and `meta.request_id` for each page. ## Wallet Attribution Hyperliquid fills carry `user_address` wherever the venue reports it, so the tape answers wallet-level questions directly: what one account filled in a window, whether it made or took liquidity on each execution, and what each fill did to its position. The TP/SL and order-history routes accept a `user` filter (the query parameter is `user`, not the `user_address` field name each record carries), which turns one wallet's risk management and order behavior into a bounded query instead of a full-tape scan. The `user` filter on order-history is order lifecycle, not fill retrieval. Use it when the question is about an order's placed, partially filled, filled, or canceled state, not as a replacement for the fill tape. ## Native `userFills` terminology Native Hyperliquid `userFills` maps to 0xArchive `trades`. 0xArchive has no WebSocket channel named `userFills`; subscribe to the venue's `trades` channel and apply client-side attribution instead. ## TP/SL Lifecycle Around Fills A take-profit or stop-loss rests as a trigger order until its price condition fires, and when it fires it becomes an ordinary fill. To follow that lifecycle, pair `/v1/hyperliquid/orders/{symbol}/tpsl` for the triggers with `/v1/hyperliquid/trades/{symbol}` for the resulting executions, joining on the order that placed the trigger. A trigger that never fired and one that fired are different events; the status field separates them. ## Coverage Window Hyperliquid native L2 and trade rows have observed floors in April 2023. Core and HIP-3 order-level (L4) history has an observed floor of March 10, 2026; HIP-4 begins May 2, 2026. Spot order-event diffs can precede the first reconstructable checkpoint, so probe those routes separately. Check the exact window and any gaps for your symbols on [Venue coverage](/venue-coverage) and [Data quality](/data-quality) before a backtest or export depends on the output. ## Maker And Taker Analysis The `crossed` flag and fee sign support maker/taker studies when those fields are present. Count taker fills against maker fills for one wallet, sum signed fees to separate cost from rebate income, and use `direction` with `start_position` to tell opening flow from closing flow inside the same window. Treat optional attribution and position fields as nullable; do not assume every row carries the same enrichment. ## Stream Fills Live The `trades` channel streams fills as they execute. Order events, including trigger placements and cancels, stream through `l4_orders`. ```javascript theme={"theme":"github-dark"} ws.send(JSON.stringify({ op: "subscribe", channel: "trades", symbol: "BTC" })); ``` Connection and reconnect handling live in the [WebSocket](/websocket) tab; the [Hyperliquid WebSocket Streaming API](/hyperliquid-websocket-streaming-api) page covers live channels and historical replay on one socket. See the [Hyperliquid market data API](https://0xarchive.io/hyperliquid) for other data types. ## Next Step Open [Trades](/rest-api/trades) for the route contract, [Hyperliquid REST](/rest-api/hyperliquid) for the core perp family, and [Hyperliquid Order Book Data API](/hyperliquid-order-book-data-api) when the job needs the book those fills executed against. For order-level depth, start with [L4 order books](/rest-api/order-books-l4). This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.