# Canonical: https://www.uddalak.xyz/hyperliquid-academy/article/93-hyperliquid-exchange-endpoint-guide
# Author: Uddalak Das
# Last source: https://www.uddalak.xyz/hyperliquid-academy/article/93-hyperliquid-exchange-endpoint-guide

---
title: "Hyperliquid Exchange Endpoint Guide"
description: "The Exchange endpoint submits signed HyperCore actions such as orders, cancels, transfers, staking, vault operations, API-wallet approvals, and account configuration."
pillar: "Architecture & Build"
track: "Architecture & Build"
cluster: "Architecture & Build"
level: "Advanced"
primary_icp: ["builder", "trader"]
secondary_icp: ["institutional decision-maker"]
content_type: "reference"
reading_time: "3 min"
last_reviewed: "2026-09-07"
last_verified: "2026-09-07"
volatile: true
prerequisites: ["87-how-hyperliquid-api-signing-works"]
related: ["94-production-grade-hyperliquid-trading-bot", "89-designing-api-wallets-for-trading-systems"]
---

# Hyperliquid Exchange Endpoint Guide

`POST /exchange` is Hyperliquid's action surface. A request contains the action payload, nonce, signature, and context such as a vault or subaccount address where applicable. The same endpoint carries many action types, so production clients should treat each action schema as a distinct typed command rather than building loosely structured JSON by hand.

## Trading actions

Orders, cancellations, TWAPs, scheduled cancels, and related trading controls use the Exchange endpoint. Time-in-force values such as GTC, IOC, and ALO change the behavior of limit orders.

A client order ID can help reconcile local intent with exchange state.

## Account and asset actions

The endpoint also includes spot transfers, generalized asset transfers between supported domains, withdrawals, staking operations, vault transfers, API-wallet approvals, builder-fee approvals, and account-abstraction configuration.

These are higher-authority operations than an ordinary order. Permission and signing policy should reflect that.

## Subaccounts and vaults

Subaccounts and vaults do not have independent private keys in the normal sense. The master signer submits actions with the relevant target address in the request context.

If a system signs with the correct master key but omits or misroutes the target address, it can operate on the wrong account.

## Expiry and dead-man controls

Some actions support `expiresAfter`, allowing stale requests to be rejected. The schedule-cancel action acts as a dead man's switch by scheduling cancellation of open orders unless refreshed or removed.

These controls are valuable for automated systems, but they consume rate-limit capacity under documented rules and need monitoring.

## Error handling

HTTP success does not imply every order in a batch succeeded. Parse action-level statuses and errors. Reconcile the resulting order or position state before assuming the operation completed as intended.

Retries must be nonce-aware and idempotency-aware. A network timeout can mean “request failed” or “response was lost after acceptance.”

## How this connects

Start with [How Hyperliquid API Signing Works](/hyperliquid-academy/article/87-how-hyperliquid-api-signing-works) if the underlying concept is unfamiliar. Related reading: [How to Build a Production-Grade Hyperliquid Trading Bot](/hyperliquid-academy/article/94-production-grade-hyperliquid-trading-bot), [Designing API Wallets for Hyperliquid Trading Systems](/hyperliquid-academy/article/89-designing-api-wallets-for-trading-systems).

## Sources

- https://hyperliquid.gitbook.io/hyperliquid-docs/for-developers/api/exchange-endpoint
- https://hyperliquid.gitbook.io/hyperliquid-docs/for-developers/api/signing
- https://hyperliquid.gitbook.io/hyperliquid-docs/for-developers/api/nonces-and-api-wallets