START HERE

Distinguish Hyperliquid's address action quota from its IP request limit, and see when cancel requests still have capacity.

Diagram distinguishing Hyperliquid IP request limits from address action limits and the separate cancel allowance.
Original limit map based on Hyperliquid's developer documentation; check the actual API error and order state. Official reference ↗

A Hyperliquid bot operator described trading actions failing after an API quota was exhausted. The immediate question is whether an open order can still be canceled. Often, yes: Hyperliquid's current rate-limit documentation gives cancels a separate, larger cumulative allowance under the address-based action limit. It also permits a limited address one request every 10 seconds. That does not mean every cancel is guaranteed to go through; first identify which limit and error you actually hit.

Is this the address limit or the IP limit?

In an illustrative bot run, I see order actions rejected and initially call it 'the API quota.' That phrase hides two different counters. Hyperliquid documents an IP-based REST weight budget of 1,200 per minute and an address-based action budget that starts with a buffer of 10,000 requests and grows with cumulative traded USDC. An address limit applies to action requests; it does not apply to info requests. The diagram above is a routing aid, not a live quota display.

Record the exact API response and whether failures occur only for one trading address or across multiple addresses from the same IP. If information requests still succeed while actions fail for one address, the address limit is worth checking. If unrelated requests from the same IP are also throttled, inspect IP request weights and the time window. For the address branch, Hyperliquid documents a read-only userRateLimit info request using the trading address, not an API agent-wallet address. Its response includes nRequestsUsed and nRequestsCap. That observation narrows the cause; it is not a substitute for the actual error response.

Can cancels work when new orders fail?

For the address-based limit, the official formula says the cumulative cancel allowance is min(limit + 100000, limit × 2), where limit is the default action limit. Hyperliquid states that this is intended to leave room to cancel open orders after hitting the ordinary address limit. A limited address also has a slow fallback of one request every 10 seconds. If the cancel reserve is exhausted too, or a separate IP limit applies, the request may still fail.

Do not keep resending the same cancel in a tight loop. Hyperliquid notes that, under congestion, avoiding repeat cancels whose results were already returned can help. Stop the bot's automatic retries, inspect the order state with the documented read-only orderStatus query or open-order view, and only send a new cancel if the order is still open. Keep the returned order ID and response so you can reconcile what happened.

Should you batch cancels or trade to restore quota?

Batching has two different effects. The documentation counts a batch as one request for IP limits, but as the number of individual cancels for address limits. Large batches can still carry extra IP weight under the documented weight formula. Batching may reduce IP pressure without eliminating address usage. The docs also describe a relationship between action allowance and cumulative trading volume; that is not a reason to place a risky trade merely to raise a limit. Confirm current order state and use the official API documentation or Hyperliquid support for account-specific failures.

This guide is for API operators, not a promise that a position can always be closed during a service problem. HideFi is independent of Hyperliquid and cannot operate or recover an account.

Official sources

Product interfaces and recovery policies can change. Confirm the current steps before acting.