Overview

Quicknode's Hyperliquid Exchange API provides REST endpoints for trading operations on HyperCore: placing and canceling orders, modifying positions, and managing builder fee approvals. All write operations require an EIP-712 signature from the controlling wallet.

Quicknode's implementation is not a direct proxy of Hyperliquid's /exchange endpoint (https://api.hyperliquid.xyz/exchange). It was rebuilt based on user feedback. If your application currently uses the native foundation API, your integration will need to be adapted. Build endpoints accept human-readable parameters rather than wire format, transaction submission is split into a Build step and a Send step, and Quicknode extends the foundation API with enhanced endpoints for order validation, enriched order queries, and market discovery. You can route requests through your Quicknode endpoint, which proxies to https://api.hyperliquidapi.com, or call https://api.hyperliquidapi.com directly to minimize hops if your workload is latency sensitive.

info

Exchange API calls do not consume Quicknode API credits. A builder fee is appended to all submitted transactions. See hyperliquidapi.com for the fee schedule. Free trial users receive a shared URL that is not account-specific. To white-label with your own builder code, contact us.

The API is organized into three groups:

• Build - Construct unsigned actions and receive a hash to sign. No signature required. Builder fees are injected at this step.
• Send - Submit pre-built, signed actions to the exchange. Requires the signature produced by your wallet.
• Enhanced Endpoints - Read-only and utility endpoints for querying order state, validating actions before submission, and discovering available markets.

All Exchange API calls go to your Quicknode endpoint with the /hypercore prefix:

https://your-endpoint.quiknode.pro/hypercore/exchange   # build and send actions
https://your-endpoint.quiknode.pro/hypercore/approval   # check builder fee approval
https://your-endpoint.quiknode.pro/hypercore/openOrders # enriched open orders
https://your-endpoint.quiknode.pro/hypercore/orderStatus
https://your-endpoint.quiknode.pro/hypercore/preflight
https://your-endpoint.quiknode.pro/hypercore/markets
https://your-endpoint.quiknode.pro/hypercore/dexes

Method Reference

Build (no signature)

These endpoints accept human-readable parameters and return a hash and nonce for your wallet to sign. The builder fee is injected automatically.

Endpoint	HTTP	Path	Description
Build Order	POST	/hypercore/exchange	Build a limit or IOC order
Build Market Order	POST	/hypercore/exchange	Build a market order (fetches mid price, applies 3% slippage)
Build Close Position	POST	/hypercore/exchange	Build a market close for an open position
Build Cancel	POST	/hypercore/exchange	Build a cancel action for one or more orders
Build Modify	POST	/hypercore/exchange	Build a batch modify for one or more open orders
Build Approval	POST	/hypercore/exchange	Build a builder fee approval action
Build Revoke	POST	/hypercore/exchange	Build a builder fee revoke action
Build Outcome Action	POST	/hypercore/exchange	Build a HIP-4 prediction market action (outcomeSplit, outcomeMerge, outcomeMergeQuestion, outcomeNegate)
Build Priority Funding Deposit	POST	/hypercore/exchange	Build a cDeposit action to move spot HYPE to undelegated staking balance for priority fees
Build User-Signed Action	POST	/hypercore/exchange	Build a HyperliquidTransaction EIP-712 action: transfers, withdrawals, staking, account management

Send (with signature)

These endpoints accept the wire-format action returned by a build call, plus the EIP-712 signature from your wallet, and submit the action to the exchange.

Endpoint	HTTP	Path	Description
Send Order	POST	/hypercore/exchange	Submit a signed order
Send Cancel	POST	/hypercore/exchange	Submit a signed cancel
Send Modify	POST	/hypercore/exchange	Submit a signed batch modify
Send Approval	POST	/hypercore/exchange	Submit a signed builder fee approval
Send Revoke	POST	/hypercore/exchange	Submit a signed builder fee revoke
Send Outcome Action	POST	/hypercore/exchange	Submit a signed userOutcome action for HIP-4 prediction markets
Send User-Signed Action	POST	/hypercore/exchange	Submit a signed HyperliquidTransaction EIP-712 action

Enhanced Endpoints

Read-only and utility endpoints. No signature required.

Endpoint	HTTP	Path	Description
Check Approval	GET	/hypercore/approval	Check whether a builder fee approval is active for a user
Open Orders	POST	/hypercore/openOrders	Enriched open orders with pre-built cancel actions
Order Status	POST	/hypercore/orderStatus	Check order status with a plain-English explanation
Preflight	POST	/hypercore/preflight	Validate an order action before signing or submitting
List Markets	GET	/hypercore/markets	All available perp, spot, and HIP-3 markets
List Dexes	GET	/hypercore/dexes	All active HIP-3 builder DEX names

The Build/Send Pattern

Hyperliquid separates transaction construction from signing and submission. The recommended flow for placing an order:

1. Build - POST to /hypercore/exchange with your order parameters. The response includes a hash (the EIP-712 digest to sign) and the full wire-format action object with the builder fee injected.
2. Sign - Sign the hash with your wallet's private key using EIP-712. This produces an {r, s, v} signature.
3. Send - POST to /hypercore/exchange with the wire-format action, the nonce from the build response, and your signature.

# Step 1: Build
curl -X POST https://your-endpoint.quiknode.pro/hypercore/exchange \
  -H "Content-Type: application/json" \
  -d '{
    "action": {
      "type": "order",
      "orders": [{"asset": "BTC", "side": "buy", "price": "100000", "size": "0.001", "tif": "ioc"}]
    }
  }'

# Response includes: hash, nonce, action (wire format with builder fee)

# Step 2: Sign hash with your wallet (off-chain, EIP-712)

# Step 3: Send
curl -X POST https://your-endpoint.quiknode.pro/hypercore/exchange \
  -H "Content-Type: application/json" \
  -d '{
    "action": { ... },
    "nonce": 1234567890,
    "signature": {"r": "0x...", "s": "0x...", "v": 28}
  }'

If you use a Quicknode SDK (Python, TypeScript, Go, or Rust), the SDK handles signing and wraps both steps for you. See Supported Hyperliquid SDKs.

Additional Action Types

The Build and Send endpoints above cover the most common trading operations. Quicknode also supports the following action types, which can be submitted via the corresponding Build and Send pages above:

• HIP-4 prediction markets: outcomeSplit, outcomeMerge, outcomeMergeQuestion, outcomeNegate (via Build/Send Outcome Action)
• Priority funding: cDeposit, cWithdraw (via Build Priority Funding Deposit and Build User-Signed Action)
• Transfers: usdSend, spotSend, usdClassTransfer, sendAsset
• Account management: approveAgent, withdraw3, userSetAbstraction
• Staking: tokenDelegate

For action types not listed above, refer to Hyperliquid's exchange endpoint documentation.

Builder Fees

All build and send endpoints operate via Quicknode's builder infrastructure. The Exchange API does not consume Quicknode API credits; transactions are appended with a builder fee during the build step. See hyperliquidapi.com for a full fee breakdown. If you need to supply your own builder code, refer to the Hyperliquid builder codes documentation. To white-label this service with your own builder code, contact Quicknode.

Users on the free trial plan share a public endpoint that is not specific to your Quicknode account. See hyperliquidapi.com for details or join the Quicknode Discord for support.

Frequently Asked Questions

Do I need to sign every transaction?▼

Yes, for any write operation (orders, cancels, modifications, approvals). The Exchange API does not custody keys. Your wallet signs the hash returned by a build call; you pass the resulting {r, s, v} signature to the corresponding send call.

What is the difference between Build Order and Send Order?▼

Build Order accepts human-readable parameters (asset name as a string, price/size as decimal strings, time-in-force as a readable value like "gtc") and converts them to Hyperliquid wire format while injecting the builder fee. Send Order accepts the wire-format action from the build response plus your signature, and submits it to the exchange.

Can I skip the build step and send directly?▼

Yes. If you already have the wire-format action, the correct nonce, and a valid signature (for example, from a previous build call or constructed manually), you can call Send Order directly. The build endpoints are a convenience layer.

What is Preflight for?▼

Preflight validates an order action for errors before you sign or submit it. Use it to catch issues like invalid asset names, size constraints, or insufficient margin before spending a signature on a transaction that will be rejected.

What does vaultAddress do?▼

Most build and send endpoints accept an optional vaultAddress parameter. When provided, the action is submitted on behalf of the specified vault rather than the signing wallet. This is used for vault-managed trading strategies.

What does expiresAfter do?▼

Cancel and modify actions accept an optional expiresAfter timestamp (milliseconds). If the action has not been processed by the exchange before this time, it is discarded. This prevents stale cancel or modify requests from being applied unexpectedly.

How do I check whether my builder fee approval is still active?▼

Use Check Approval (GET /hypercore/approval?user=0x...). It returns the current approval status, the approved builder address, and the max fee rate for the given user address.

What is the difference between Open Orders here and openOrders in the Info Endpoint?▼

The Info Endpoint's openOrders returns raw order data. The Exchange API's Open Orders returns the same data enriched with pre-built cancel actions for each order, making it easier to construct cancel requests without a separate build step.

How do I discover available markets?▼

Use List Markets (GET /hypercore/markets) for all perp, spot, and HIP-3 markets. Use List Dexes (GET /hypercore/dexes) to get the names of all active HIP-3 builder DEXes, which you can pass as the dex parameter to info endpoints that support it.