# Canonical: https://www.uddalak.xyz/hyperliquid-academy/article/38-building-with-hyperliquid-api
# Author: Uddalak Das
# Last source: https://www.uddalak.xyz/hyperliquid-academy/article/38-building-with-hyperliquid-api

---
title: "Building With the Hyperliquid API"
description: "A practical map of the Info API, Exchange actions, signing, and the minimum architecture for a Hyperliquid application."
track: "Architecture & Build"
level: "Advanced"
primary_icp: ["builder"]
secondary_icp: ["trader", "institutional decision-maker"]
reading_time: "3 min"
last_reviewed: "2026-09-07"
---

# Building With the Hyperliquid API

A Hyperliquid application usually needs two different capabilities: **read market or account state** and **submit signed actions**. Treating those as separate paths makes the API easier to reason about.

```mermaid
flowchart LR
    A[Frontend or service] -->|read| B[Info API]
    B --> C[Market and account state]
    A -->|signed action| D[Exchange endpoint]
    D --> E[HyperCore]
    E --> F[Orders, transfers, cancels]
```

## Read through the Info API

The Info API exposes data such as market metadata, order books, candles, open orders, fills, positions, and other account or market state. Many read requests use a typed JSON payload rather than a large collection of unrelated URL paths.

For production applications, builders should cache stable metadata and avoid repeatedly requesting data that changes rarely.

## Write through signed Exchange actions

Placing orders, cancelling orders, transferring funds, and other account mutations require authenticated actions. Hyperliquid uses cryptographic signatures rather than a conventional server-issued username and password session.

Many applications use an **API wallet**, also called an agent wallet, so the user's main wallet does not need to sign every trading action. The agent has its own key and authorization relationship to the master account.

## The minimum application architecture

A simple trading product may contain:

- a frontend for user intent
- a backend or local signer for controlled key handling
- Info API requests for state
- WebSocket subscriptions for live updates
- Exchange actions for orders and cancels
- local reconciliation so the product knows which requests became fills

## Build around failure, not only the happy path

Professional integrations should explicitly handle rate limits, duplicate or stale nonces, network retries, partial fills, rejected orders, disconnects, and state reconciliation after downtime.

The exchange response to an order submission is not the same thing as a final trading outcome. A robust application continuously reconciles orders, fills, balances, and positions with authoritative Hyperliquid state.

Hyperliquid exposes relatively low-level market infrastructure. That is powerful for builders, but it means production reliability is partly the application's responsibility.

## Sources

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