> ## Documentation Index > Fetch the complete documentation index at: https://docs.hypedexer.com/llms.txt > Use this file to discover all available pages before exploring further. # Indexed fills (compact shape) > Stored fills of the index with filters, in the compact shape (numbers as numbers, `time` in ISO 8601). Same data as `GET /fills/` on the Indexed Data REST API. `market` selects `perp` (default when `user` is set, indexed since 2024-11-18), `spot` or `hip3`. `timeRange` (`1h`, `24h`, `7d`, `30d`) overrides `startTime` / `endTime`; without any of them, the last 7 days. Sorted by time (`order`), then `tid`. Paging: on perp fills use the `X-Next-Cursor` response header as `cursor` while `X-Has-More` is `true` (keyset on `(time_ms, tid)`, no gaps even when many fills share a millisecond); `offset` is also accepted. `X-Total-Count` gives the total matching count. Every row carries `twapId` (`null` = ordinary fill), `crossed`, `cloid`, `builderFee` and `builder`. `recentFills` takes the same parameters for the last 24 hours. ## OpenAPI ````yaml /live-data/openapi-rest.json post /info#fills openapi: 3.0.3 info: title: 'Hypedexer API: Live Data (REST)' version: 0.1.0 description: >- REST API for real-time Hyperliquid market data served from our own Hyperliquid nodes. All data is accessed through a single unified endpoint `POST /info` that dispatches based on the `type` field in the JSON body. ## Request types | Type | Description | Handled | |------|-------------|----------| | `metaAndAssetCtxs` | Asset context (funding, OI, prices) | Locally (Redis cache) | | `allMids` | Mid prices for all coins | Locally (Redis cache) | | `userFills` / `userFillsByTime` | Fills for a specific user | Locally (volume files) | | `allFills` | All fills globally | Locally (volume files) | | `trades` | Trade data | Locally (volume files) | | `l2Book` / `l2Books` | L2 order book snapshot | Locally | | `availableDates` | Available data dates | Locally | | `clearinghouseState` | Clearinghouse state (single/multi-user) | Locally with upstream proxy per user | | `userFunding` / `accountFunding` | Funding payments of a user | Indexed history, returned unwrapped | | `userNonFundingLedgerUpdates` | Native ledger of a user: deposits, withdrawals, transfers, vaults, staking, borrow/lend | Indexed history, returned unwrapped | | `historicalOrders` | Latest orders of a user with their status | Indexed history, returned unwrapped | | `userTwapSliceFills` | Fills of a user's TWAP orders with their parent | Indexed history, returned unwrapped | | `fills` / `recentFills` | Indexed fills with filters (compact shape) | Indexed history, returned unwrapped; paging in `X-Has-More` / `X-Next-Cursor` headers | | `dataCoverage` | Start and latest timestamp per dataset | Indexed history | | `borrowLendReserveHistory` | Borrow/lend reserve history, one sample per minute | Indexed history, returned unwrapped | | `meta`, `spotMeta`, `openOrders`, ... | Proxied to local Hyperliquid node | Proxied to upstream | ## Authentication Optional. When `API_KEY` is configured on the server, all requests must include: ``` Authorization: Bearer ``` ## Response format Most types return: ```json { "result": , "cursor": null } ``` `allMids` returns the result directly (not wrapped): ```json { "BTC": "66764.5", "ETH": "3421.2" } ``` Proxied types return the upstream response as-is. contact: name: Hypedexer servers: - url: https://api.hypedexer.com description: Production, routed to the nearest region (EU or JP) security: - BearerAuth: [] tags: - name: Health description: Service health and info. - name: Asset Context description: >- Real-time asset context data: funding, open interest, oracle/mark/mid prices, volumes. - name: Mid Prices description: Mid prices for all coins, optionally filtered by DEX. - name: Fills description: >- Executed fills from the Hyperliquid fullnode volumes. Supports user-specific and global queries. - name: Trades description: Trade data from the fullnode volumes. - name: Order Book description: L2 order book snapshots. - name: Metadata description: Volume availability and data metadata. - name: Clearinghouse description: >- Clearinghouse state with multi-user support. Each user is fetched individually from the upstream Hyperliquid node. - name: Proxied Perpetuals description: >- Perpetual market metadata, margin, OI caps, DEX configs. Proxied to upstream Hyperliquid node. - name: Proxied Spot description: >- Spot market metadata, balances, and deploy state. Proxied to upstream Hyperliquid node. - name: Proxied Trading description: >- Orders, positions, and active asset data. Proxied to upstream Hyperliquid node. - name: Proxied Account description: >- User account info: fees, rate limits, sub-accounts, agents, roles. Proxied to upstream Hyperliquid node. - name: Proxied Vaults description: >- Vault summaries, equities, and leaderboards. Proxied to upstream Hyperliquid node. - name: Proxied Staking description: >- Delegations, staking summaries, and validator votes. Proxied to upstream Hyperliquid node. - name: Proxied Exchange description: >- Exchange status, liquidatable positions, web data. Proxied to upstream Hyperliquid node. - name: Account History description: >- Per-address history served from our index, in Hyperliquid's `info` shapes: funding payments, native ledger and orders. - name: Borrow/Lend description: >- History of Hyperliquid's borrow/lend reserves, sampled every minute from our own node. - name: Coverage description: >- What the index holds: per-dataset start and latest timestamp in the region answering. paths: /info#fills: post: tags: - Fills summary: Indexed fills (compact shape) description: >- Stored fills of the index with filters, in the compact shape (numbers as numbers, `time` in ISO 8601). Same data as `GET /fills/` on the Indexed Data REST API. `market` selects `perp` (default when `user` is set, indexed since 2024-11-18), `spot` or `hip3`. `timeRange` (`1h`, `24h`, `7d`, `30d`) overrides `startTime` / `endTime`; without any of them, the last 7 days. Sorted by time (`order`), then `tid`. Paging: on perp fills use the `X-Next-Cursor` response header as `cursor` while `X-Has-More` is `true` (keyset on `(time_ms, tid)`, no gaps even when many fills share a millisecond); `offset` is also accepted. `X-Total-Count` gives the total matching count. Every row carries `twapId` (`null` = ordinary fill), `crossed`, `cloid`, `builderFee` and `builder`. `recentFills` takes the same parameters for the last 24 hours. operationId: indexedFills requestBody: required: true content: application/json: schema: type: object required: - type properties: type: type: string enum: - fills market: type: string enum: - perp - spot - hip3 user: type: string coin: type: string coins: type: array items: type: string description: Several coins (spot only) dexId: type: string description: HIP-3 dex id (hip3 only) side: type: string enum: - A - B sizeUsd: type: number minimum: 0 description: Minimum notional in USD startTime: type: integer description: Epoch ms, inclusive endTime: type: integer description: Epoch ms, inclusive timeRange: type: string enum: - 1h - 24h - 7d - 30d offset: type: integer minimum: 0 default: 0 limit: type: integer minimum: 1 maximum: 5000 default: 100 cursor: type: string description: '`X-Next-Cursor` of the previous page (perp only)' order: type: string enum: - ASC - DESC default: DESC hasPriorityGas: type: boolean example: type: fills user: '0x01f63d95156bca41c98a9817f0627c3521196f7f' startTime: 1790339680000 endTime: 1790339990000 limit: 100 responses: '200': description: Fills headers: X-Has-More: description: '`true` when a next page exists' schema: type: string enum: - 'true' - 'false' X-Next-Cursor: description: Value to pass as `cursor` for the next page schema: type: string X-Total-Count: description: Total number of matching fills schema: type: string content: application/json: schema: type: array items: type: object properties: user: type: string coin: type: string coinMeaning: type: string description: Human-readable market name (spot pairs, HIP-3) px: type: number sz: type: number side: type: string enum: - A - B time: type: string description: >- ISO 8601 UTC, exact millisecond (`2026-09-25T12:39:48.007000`) startPosition: type: number dir: type: string closedPnl: type: number hash: type: string oid: type: integer tid: type: integer crossed: type: integer enum: - 0 - 1 description: >- 1 = taker. Reliable on fills stored since 2026-09-24 15:53 UTC cloid: type: string nullable: true fee: type: number description: Trading fee, builder fee excluded feeToken: type: string typeTrade: type: string enum: - perp - spot - hip3 isLiquidation: type: integer liquidationRole: type: string liqMarkPx: type: number nullable: true liqMethod: type: string nullable: true liquidatedUser: type: string nullable: true notional: type: number priorityGas: type: number nullable: true twapId: type: integer nullable: true description: Parent TWAP id; `null` = ordinary fill builderFee: type: number nullable: true description: Separate from `fee` builder: type: string nullable: true example: - user: '0x01f63d95156bca41c98a9817f0627c3521196f7f' coin: BTC coinMeaning: BTC px: 84500 sz: 0.08689 side: B time: '2026-09-25T12:39:48.007000' startPosition: 1.97038 dir: Open Long closedPnl: 0 hash: >- 0x0000000000000000000000000000000000000000000000000000000000000000 oid: 556339025730 tid: 573707782165198 crossed: 1 cloid: null fee: 0 feeToken: USDC typeTrade: perp isLiquidation: 0 liquidationRole: none liqMarkPx: null liqMethod: null liquidatedUser: null notional: 7342.205 priorityGas: null twapId: 2254205 builderFee: null builder: null '401': $ref: '#/components/responses/Unauthorized' security: - BearerAuth: [] components: responses: Unauthorized: description: >- Missing or invalid API key. The body is `missing api key` or `invalid api key`. content: application/json: schema: $ref: '#/components/schemas/ErrorResponse' example: error: Invalid API key schemas: ErrorResponse: type: object required: - error properties: error: type: string description: Error message securitySchemes: BearerAuth: type: http scheme: bearer description: >- Your Hypedexer API key, sent as `Authorization: Bearer `. The `X-API-Key: ` header and the `api_key` query parameter are accepted as well. ````