> ## 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.

# User TWAP slice fills

> Fills executed by the wallet's TWAP orders, each with its parent `twapId`, in Hyperliquid's shape `[{fill, twapId}]`. Every TWAP fill carries its parent as soon as it is indexed (seconds), from 2025-09-01. Newest first, then by `tid`; `startTime` / `endTime` are inclusive bounds on the fill time (default: last 7 days). `twapId` restricts the result to one parent. The same association is available in bulk on indexed fills: `fills` returns `twapId` on every row (`null` = ordinary fill). Parent metadata (requested size, executed size, status) comes from `userTwapSummaries` / `userTwapStatusesByTime`.

Example: TWAP 2254205, a five-minute BTC TWAP of 1 BTC started 2026-09-25 12:34:47 UTC, has 30 slice fills.



## OpenAPI

````yaml /live-data/openapi-rest.json post /info#userTwapSliceFills
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 <API_KEY>

    ```


    ## Response format


    Most types return:

    ```json

    { "result": <data>, "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#userTwapSliceFills:
    post:
      tags:
        - Account History
      summary: User TWAP slice fills
      description: >-
        Fills executed by the wallet's TWAP orders, each with its parent
        `twapId`, in Hyperliquid's shape `[{fill, twapId}]`. Every TWAP fill
        carries its parent as soon as it is indexed (seconds), from 2025-09-01.
        Newest first, then by `tid`; `startTime` / `endTime` are inclusive
        bounds on the fill time (default: last 7 days). `twapId` restricts the
        result to one parent. The same association is available in bulk on
        indexed fills: `fills` returns `twapId` on every row (`null` = ordinary
        fill). Parent metadata (requested size, executed size, status) comes
        from `userTwapSummaries` / `userTwapStatusesByTime`.


        Example: TWAP 2254205, a five-minute BTC TWAP of 1 BTC started
        2026-09-25 12:34:47 UTC, has 30 slice fills.
      operationId: userTwapSliceFills
      requestBody:
        required: true
        content:
          application/json:
            schema:
              type: object
              required:
                - type
                - user
              properties:
                type:
                  type: string
                  enum:
                    - userTwapSliceFills
                user:
                  type: string
                startTime:
                  type: integer
                  description: 'Inclusive, epoch ms. Default: now minus 7 days'
                endTime:
                  type: integer
                  description: Inclusive, epoch ms
                twapId:
                  type: integer
                  description: Only the slices of this parent
                limit:
                  type: integer
                  minimum: 1
                  maximum: 5000
                  default: 500
            example:
              type: userTwapSliceFills
              user: '0x01f63d95156bca41c98a9817f0627c3521196f7f'
              twapId: 2254205
              limit: 100
      responses:
        '200':
          description: Slice fills, newest first
          content:
            application/json:
              schema:
                type: array
                items:
                  type: object
                  properties:
                    fill:
                      type: object
                      properties:
                        coin:
                          type: string
                        px:
                          type: string
                        sz:
                          type: string
                        side:
                          type: string
                          enum:
                            - A
                            - B
                        time:
                          type: integer
                          description: Exact fill time in milliseconds
                        startPosition:
                          type: string
                        dir:
                          type: string
                        closedPnl:
                          type: string
                        hash:
                          type: string
                        oid:
                          type: integer
                        crossed:
                          type: boolean
                          description: >-
                            `true` when the fill took liquidity (taker).
                            Reliable on fills stored since 2026-09-24 15:53 UTC
                        tid:
                          type: integer
                        fee:
                          type: string
                          description: Trading fee, builder fee excluded
                        feeToken:
                          type: string
                        twapId:
                          type: integer
                          nullable: true
                          description: Parent TWAP id; `null` for an ordinary fill
                        cloid:
                          type: string
                          description: Client order id, present only when the order had one
                        builderFee:
                          type: string
                          description: >-
                            Builder fee, separate from `fee`; present only when
                            a builder code was used
                        builder:
                          type: string
                          description: >-
                            Builder address, present only when a builder code
                            was used
                    twapId:
                      type: integer
              example:
                - fill:
                    coin: BTC
                    px: '84500'
                    sz: '0.08689'
                    side: B
                    time: 1790339988007
                    startPosition: '1.97038'
                    dir: Open Long
                    closedPnl: '0'
                    hash: >-
                      0x0000000000000000000000000000000000000000000000000000000000000000
                    oid: 556339025730
                    crossed: true
                    tid: 573707782165198
                    fee: '0'
                    feeToken: USDC
                  twapId: 2254205
        '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 <key>`. The
        `X-API-Key: <key>` header and the `api_key` query parameter are accepted
        as well.

````