Hyperliquid Docs
  • About Hyperliquid
    • Core contributors
  • Onboarding
    • How to start trading
    • How to use the HyperEVM
    • Connect mobile via QR code
    • Export your email wallet
    • Testnet faucet
  • HyperCore
    • Overview
    • Bridge
    • API servers
    • Clearinghouse
    • Oracle
    • Order book
    • Staking
    • Vaults
      • Protocol vaults
      • For vault leaders
      • For vault depositors
    • Multi-sig
  • HyperEVM
    • Tools for HyperEVM builders
  • Hyperliquid Improvement Proposals (HIPs)
    • HIP-1: Native token standard
    • HIP-2: Hyperliquidity
    • HIP-3: Builder-Deployed Perpetuals
    • Frontend checks
  • Trading
    • Perpetual assets
    • Contract specifications
    • Margin tiers
    • Fees
    • Builder codes
    • Order book
    • Order types
    • Take profit and stop loss orders (TP/SL)
    • Margining
    • Liquidations
    • Entry price and pnl
    • Funding
    • Miscellaneous UI
    • Auto-deleveraging
    • Robust price indices
    • Self-trade prevention
    • Portfolio graphs
    • Hyperps
    • Market making
  • Validators
    • Running a validator
    • Delegation program
  • Referrals
    • Staking referral program
  • Points
  • Historical data
  • Risks
  • Bug bounty program
  • Audits
  • Brand kit
  • For developers
    • API
      • Notation
      • Asset IDs
      • Tick and lot size
      • Nonces and API wallets
      • Info endpoint
        • Perpetuals
        • Spot
      • Exchange endpoint
      • Websocket
        • Subscriptions
        • Post requests
        • Timeouts and heartbeats
      • Error responses
      • Rate limits
      • Bridge2
      • Deploying HIP-1 and HIP-2 assets
      • Deploying HIP-3 assets
    • HyperEVM
      • Dual-block architecture
      • Raw HyperEVM block data
      • Interacting with HyperCore
      • HyperCore <> HyperEVM transfers
      • Wrapped HYPE
      • JSON-RPC
    • Nodes
      • Reading L1 Data
Powered by GitBook
On this page
  1. For developers
  2. API

Error responses

Order and cancel errors are usually returned as a vector with same length as the batched request.

Below is a list of possible batched error responses:

Error source
Error type
Error string

Order

Tick

Price must be divisible by tick size.

Order

MinTradeNtl

Order must have minimum value of $10

Order

Margin

Insufficient margin to place order.

Order

ReduceOnly

Reduce only order would increase position.

Order

BadAloPx

Post only order would have immediately matched, bbo was {bbo}.

Order

IocCancel

Order could not immediately match against any resting orders.

Order

BadTriggerPx

Invalid TP/SL price.

Order

MarketOrderNoLiquidity

No liquidity available for market order.

Cancel

MissingOrder

Order was never placed, already canceled, or filled.

Important: Some errors are a deterministic function of the payload itself, and these are instead returned earlier as part of pre-validation. In this case only one error is returned for the entire payload, as some of these errors do not apply to a specific order or cancel.

Examples include: empty batch of orders, non-reduce-only TP/SL orders, and some forms of tick size validation.

For API users that use batching, it's recommended to handle the case where a single error is returned for a batch of multiple orders. In this case, the response could be duplicated ntimes before being sent to the callback function, as the whole batch was rejected for this same reason.

PreviousTimeouts and heartbeatsNextRate limits

Last updated 3 months ago