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

# Data coverage per dataset

> For each dataset, `from` (start of complete coverage, UTC) and `latest` (the most recent event timestamp present in the region answering your request), plus `delaySeconds` (now minus `latest`). Use it to tell an empty answer from a window that is not covered: a window is covered when `from` ≤ window ≤ `latest`.

- `fills`, `spotFills`, `userFunding`, `ledger`, `twaps`, `liquidations`: exact latest event timestamp. Funding settles hourly, so its delay grows to about an hour between settlements.
- `orders`: `lastWrite` (time of the last write; the indexer follows the chain within seconds) instead of `latest`; order statuses live in the EU region only.
- Answers are cached 30 seconds. No parameters.



## OpenAPI

````yaml /live-data/openapi-rest.json post /info#dataCoverage
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#dataCoverage:
    post:
      tags:
        - Coverage
      summary: Data coverage per dataset
      description: >-
        For each dataset, `from` (start of complete coverage, UTC) and `latest`
        (the most recent event timestamp present in the region answering your
        request), plus `delaySeconds` (now minus `latest`). Use it to tell an
        empty answer from a window that is not covered: a window is covered when
        `from` ≤ window ≤ `latest`.


        - `fills`, `spotFills`, `userFunding`, `ledger`, `twaps`,
        `liquidations`: exact latest event timestamp. Funding settles hourly, so
        its delay grows to about an hour between settlements.

        - `orders`: `lastWrite` (time of the last write; the indexer follows the
        chain within seconds) instead of `latest`; order statuses live in the EU
        region only.

        - Answers are cached 30 seconds. No parameters.
      operationId: dataCoverage
      requestBody:
        required: true
        content:
          application/json:
            schema:
              type: object
              required:
                - type
              properties:
                type:
                  type: string
                  enum:
                    - dataCoverage
            example:
              type: dataCoverage
      responses:
        '200':
          description: Coverage per dataset
          content:
            application/json:
              schema:
                type: object
                properties:
                  generatedAt:
                    type: string
                  datasets:
                    type: object
                    additionalProperties:
                      type: object
                      properties:
                        from:
                          type: string
                        latest:
                          type: string
                          nullable: true
                        lastWrite:
                          type: string
                        delaySeconds:
                          type: integer
                          nullable: true
              example:
                generatedAt: '2026-09-28T13:08:49Z'
                datasets:
                  fills:
                    from: '2024-11-18T00:00:00Z'
                    latest: '2026-09-28T13:08:48Z'
                    delaySeconds: 1
                  spotFills:
                    from: '2024-11-18T00:00:00Z'
                    latest: '2026-09-28T13:08:47Z'
                    delaySeconds: 2
                  orders:
                    from: '2026-06-27T00:00:00Z'
                    latest: null
                    lastWrite: '2026-09-28T13:08:47Z'
                    delaySeconds: 2
                  twaps:
                    from: '2025-09-01T00:00:00Z'
                    latest: '2026-09-28T13:07:39Z'
                    delaySeconds: 70
                  userFunding:
                    from: '2025-09-27T10:00:00Z'
                    latest: '2026-09-28T13:00:00Z'
                    delaySeconds: 529
                  ledger:
                    from: '2025-09-27T09:29:00Z'
                    latest: '2026-09-28T13:08:44Z'
                    delaySeconds: 5
                  liquidations:
                    from: '2025-03-22T00:00:00Z'
                    latest: '2026-09-28T13:08:28Z'
                    delaySeconds: 21
        '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.

````