Funding data can describe a rate published for a contract or payments recorded for one account. Those answer different questions. This walkthrough uses Hyperliquid’s public documentation and read-only BTC history queries checked on 27 September 2026. Endpoint fields and venue rules can change, and the examples do not describe another exchange.
Choose the endpoint for the question
Hyperliquid documents fundingHistory for a coin’s historical rates and userFunding for funding records tied to a public account address. The first can help study contract conditions; the second can help reconcile an account’s recorded cash flows. A rate series alone cannot establish what a particular account paid or received.
Both requests use a JSON POST to https://api.hyperliquid.xyz/info. For a UTC day of BTC rates, the request body can be written as:
{
"type": "fundingHistory",
"coin": "BTC",
"startTime": 1790208000000,
"endTime": 1790294399999
}
Those millisecond timestamps bound 24 September 2026 UTC; the documented start and end are inclusive, so the final value is the last millisecond of that UTC day. The coin identifier must match the market being queried. The current API page also shows coin namespaced with a perp DEX identifier for some markets. Hyperliquid’s funding documentation says HIP-3 perps use a different premium formula, so check the specific contract’s market name and funding rules instead of assuming first-perp settings apply.
On 27 September 2026, this BTC window returned 24 rows. The first row was timestamped 1790208000045 and the last 1790290800038, both within the requested UTC day and about one hour apart. A response excerpt contained coin: BTC, fundingRate: 0.0000125, a premium field and a millisecond time. This is a reproducible API observation for one market and one date, not evidence about future funding, a strategy result, or a universal response size.
Paginate long history without losing the boundary
Hyperliquid’s general info-endpoint documentation says a time-range response is limited to 500 elements or distinct blocks. For a longer range, it instructs clients to use the last returned timestamp as the next request’s startTime. That is the documented continuation rule for this API; keep the precise request and response for each page because a page boundary can be included twice.
A read-only BTC query from 1 September through 26 September 2026 returned 500 rows on its first request. Its final row was at 2026-09-21T19:00:00.031Z. Continuing with that row’s millisecond timestamp returned 125 more rows, beginning at the same timestamp. Across those responses, 625 raw rows contained one repeated (coin, time) boundary and 624 unique observations; the final unique row was at 2026-09-26T23:00:00.010Z. The observed times were approximately hourly in that sample. This example is an API snapshot checked 27 September, not a guarantee about later history or other markets.
Preserve the response bytes first, then validate page order, requested coin, time bounds, row counts and the actual overlap. If the same market and exact timestamp appears in adjacent pages, retain both raw copies in the archive and deduplicate that confirmed boundary in the analysis view. Include the market identifier in the key: equal timestamps from different contracts are not duplicates. If the overlap is absent, the pages have an unexpected gap, or a repeated key occurs inside a page, stop and investigate instead of silently deleting or filling rows. Keep the retrieval timestamp and every request body alongside the output so a later refresh does not overwrite the evidence.
The docs describe a maximum response size for time-range queries, but not every failure mode or a permanent service-level guarantee. Use a conservative request cadence and follow the current rate-limit page when retrieving many pages. A capped response should prompt pagination; it does not tell you that the remaining time range has no records.
Preserve units, cadence and sign
The API returns numeric values as strings in its examples. Parse them as decimal numbers without converting a rate such as 0.0000125 into 0.0000125%: multiplied by 100, it is 0.00125% for the interval represented. Hyperliquid’s funding page describes its hourly settlement, positive-rate direction and venue-specific calculation. Confirm the page again before publishing a dated numerical example; do not annualize an hourly observation and present it as a forecast.
For scale only, a $10,000 notional multiplied by an assumed settled rate of 0.0000125 has a $0.125 payment magnitude for that interval under a simplified linear calculation. Which side pays depends on the rate sign and position direction. The venue’s documented calculation uses position size and the spot oracle price; actual account records and instrument details govern reconciliation. This arithmetic excludes price changes, fees and every other account event.
Validate the series before using it
Archive the exact request body, market identifier, retrieval time and unmodified response. Convert each millisecond timestamp to UTC and sort by time. Check the observed cadence, expected row count for the requested range, duplicates, missing intervals, unexpected coin names, nulls and values that fail numeric parsing. Compare the first and last returned times with the requested bounds. For long ranges, follow the documented continuation rule above, compare each page boundary, and record the rows excluded from any deduplicated analysis table.
Missing observations remain unknown. Do not fill a blank hour with zero, carry a rate forward, or join the nearest record without labeling the choice. For a bar-based test, define whether a rate observed at a settlement timestamp applies before or after that timestamp, and align it with the venue’s funding event and position snapshot. Store source timestamps in UTC even if a chart later displays local time.
Reconcile account payments separately
The documented userFunding request takes an account address and an inclusive start time in milliseconds; the end time is optional and defaults to current time. Its response example contains a funding delta with fields such as coin, fundingRate, position size, signed USDC amount and event time. Compare those event records with the account’s position and venue ledger before calling any amount realized. Do not join a public market rate to an account payment only by date or assume every account had a position at every settlement.
An account address can reveal activity even though this history request does not use a secret key. Avoid publishing someone else’s address or account history without a clear reason and consent. Do not place private keys, seed phrases or signing credentials in a read-only information query.
SuperQuant accepts user-supplied funding inputs and includes synthetic sample data; it does not claim to archive a complete, independently verified Hyperliquid history. Use the funding-rate explainer, historical-data checks, fees and funding worksheet and perpetual funding settlement audit worksheet to keep per-event venue rules, raw rates and account-reported payments together. The worksheet is a recordkeeping aid, not a connector to Hyperliquid or proof that a payment settled. This is a source walkthrough, not investment advice or an endorsement of a venue.