Three New Endpoints In The Hyperliquid Analytics API: Entry Signals, Usage, Borrow Lend

Three endpoints went live on the v1 API today: /api/v1/entry-signals, /api/v1/usage and /api/v1/borrow-lend. The first one exposes something that until now only existed as markers on a chart, a confluence engine that fires only when at least three of six independent orderflow logics agree on the same bar, and ships entry, stop and two targets with it.

All three read from the same cache layer the dashboard reads. None of them adds a single request to Hyperliquid. That constraint shaped what they return and how honest they are about freshness.

Entry Signals Come With Entry, Stop And Two Targets

GET /api/v1/entry-signals returns the confluence setups computed every 60 seconds across the top 12 Hyperliquid pairs by 24 hour volume, on both the 5 minute and the 15 minute timeframe.

A setup fires when three or more of six logics line up on the same closed bar: liquidity grab, flow rejection, absorption, CVD divergence, structure shift, level confluence. The response carries which of the six actually triggered, so a grade A setup with all six agreeing is distinguishable from a grade C with the minimum three. Each row also carries a plan object with entry, stop, t1, t2 and the R multiple of each target.

Filters are symbol, timeframe (5m or 15m), min_grade (A, B or C), confirmed_only and include_vetoed. Vetoed setups are excluded by default: when the engine finds a counter condition it flags the setup rather than deleting it, and most integrations want it gone.

Two behaviours matter if you are polling this from a bot. The id is deterministic, built from symbol, bar timestamp and side, so dedup on it and never on a timestamp alone. And a symbol outside the covered roster returns 404 with the list of covered symbols in the body instead of an empty page, because coverage rotates with volume and an empty array would read as a quiet market rather than a pair that dropped out.

Check Your Rate Limit Before You Collect A 429

GET /api/v1/usage answers one question: how much of today's quota has this key spent. It returns tier, the daily limit, requests used, requests remaining and seconds to reset, and it has no tier gate. Any valid key can read its own usage.

The limit it reports is the limit actually enforced on that key, read from the same resolution path that enforces it rather than recomputed from a published table. That distinction is not cosmetic. Keys can sit on a legacy allowance from a previous plan, and in that case the endpoint returns a quota_notice block with the date that allowance ends. The published rate limit table tells you what a tier includes. This endpoint tells you what your key has.

One detail worth pinning in your scheduler: the daily counter resets at Europe/Rome midnight, not UTC. During summer that is 22:00 UTC, and a client that assumes a UTC boundary will schedule its reset two hours early and spend part of the morning thinking it has quota it does not have. Read resets_in_seconds and stop guessing.

Borrow And Lend Reserves As A Single Call

GET /api/v1/borrow-lend returns the current Hyperliquid borrow and lend reserve state: utilization, borrow APR, supply APR and totals. It sits on the free tier because reserve state is protocol level public data.

The snapshot behind it refreshes every 15 minutes. The response carries data_age_seconds so you always know how old the numbers are, and a from_fallback flag that tells you whether the cache was cold and the values came from a live read. The values are identical either way. The flag exists so a cache miss is distinguishable from a writer that has stalled, which is the failure mode that actually costs you money when you are sizing a carry trade against a stale APR.

Every New Endpoint Reads Cache, Never The Exchange

The architectural rule behind the Hyperliquid analytics stack is that exactly one producer talks to Hyperliquid, on a schedule, inside a request budget. Every consumer reads what that producer wrote. All three endpoints follow it: entry signals read the keys the confluence cron writes every minute, borrow and lend reads the 15 minute reserve snapshot, usage reads nothing upstream at all.

The practical consequence for anyone building on the API is that polling harder does not get you fresher data. The entry signals producer runs at 60 second cadence, so a 15 second loop returns the same page four times and burns four requests from your quota. Every endpoint that has a producer behind it reports its cadence in the response, alongside the age of the data, precisely so you can size your loop to the writer instead of guessing.

There is also no WebSocket, and there will not be one soon. The platform is serverless, so a persistent connection has nowhere to live. Poll at the producer cadence and dedup on the ids.

What This Opens Up

The entry signals endpoint is the one that changes what you can build. Until now the confluence engine output lived on the chart, which meant a human had to be looking at it. Now a bot can pull grade A setups on BTC, ETH and the ten other covered pairs, read the plan object, and size a position against a stop that was computed from the same orderflow that produced the signal.

The full request and response schema for all three, including every error code and the notes on what each field does not mean, is served as JSON at buildix.trade/api/v1/docs. It is self documenting by design, no separate reference to drift out of date.

Worth being clear about what these signals are not. A confluence setup is a computed level set from six orderflow conditions agreeing, not a recommendation and not a prediction. Grade A means the conditions were unusually clean, not that the trade works. The engine publishes its inputs in the logics object for exactly that reason: you can see which three or six conditions fired and decide whether that combination is one you trade.