API reference

Catalogue of every Raydium-operated HTTP API: pool data, transaction construction, perps, the LaunchLab forum / mint / history / auth services, IPFS gateway, owner-positions, and the legacy Python API. Endpoints listed below open into an interactive playground.

Every endpoint on this site has a Try it panel powered by Mintlify’s OpenAPI playground. The playground runs in your browser and hits the live production (or devnet) hosts directly. Read Authentication before sending requests that require a wallet signature.

Service catalogue

Raydium runs eleven public HTTP services. Each one is documented as its own group in the navigation tree to the left.

Service	Mainnet host	Devnet host	What it does
API v3	api-v3.raydium.io	api-v3-devnet.raydium.io	Pool / mint / config / chain-info — the canonical read API the UI and SDK rely on.
Transaction API	transaction-v1.raydium.io	transaction-v1-devnet.raydium.io	Server-side swap / liquidity transaction construction. The aggregator entry point.
Perps API	api-perp-v1.raydium.io	—	Settings, asset metadata, RPC selection for the Raydium Perps front end.
LaunchLab Mint API	launch-mint-v1.raydium.io	launch-mint-v1-devnet.raydium.io	Token search, indexes, leaderboards, per-mint metadata for LaunchLab launches.
LaunchLab History API	launch-history-v1.raydium.io	launch-history-v1-devnet.raydium.io	Trade history, K-line aggregates for LaunchLab pools.
LaunchLab Forum API	launch-forum-v1.raydium.io	launch-forum-v1-devnet.raydium.io	Comments, threads, IPFS uploads tied to a LaunchLab launch. Wallet-signed.
LaunchLab Auth API	launch-auth-v1.raydium.io	launch-auth-v1-devnet.raydium.io	Issues short-lived ray-token JWTs from a wallet-signed message. Required to call the forum API.
Dynamic IPFS API	dynamic-ipfs.raydium.io	dynamic-ipfs-devnet.raydium.io	NFT image / metadata regenerator. Drives CLMM position art and other on-chain NFTs whose look depends on dynamic state.
Owner API	owner-v1.raydium.io	owner-v1-devnet.raydium.io	Per-wallet positions, balances, claimable rewards.
API v1	api.raydium.io	—	Legacy v1/v2 endpoints, kept live for clients that have not migrated to API v3.
Temp API	temp-api-v1.raydium.io	temp-api-v1-devnet.raydium.io	Holding pen for short-lived bespoke endpoints. Currently exposes CPMM creator-fee summaries. Subject to change without notice.

Authentication

Most services are read-only and accept anonymous requests. Two patterns appear:

• Wallet-signed handshake — required by launch-auth-v1 to mint a ray-token, then carried as the ray-token header by launch-forum-v1. Sign a Solana ed25519 message of the form time:<unix-seconds> with your wallet, send the signature + wallet address to launch-auth-v1 /request-token, receive a JWT back, and pass it as the ray-token request header on subsequent forum calls.
• No auth — every other service. Trusted callers (the Raydium UI, integrators) hit the endpoints directly over HTTPS.

The Mintlify playground lets you paste a ray-token in the auth panel before sending forum requests; the value is held in your browser only.

Rate limits

All hosts are behind Cloudflare with progressive rate limiting per source IP.

Integrators that need higher limits should contact the Raydium team. Bursts above the published limits are returned as HTTP 429 with a Retry-After header.

Response envelope

Most services wrap their JSON payloads in a uniform envelope:

{
  "id": "uuid-v4-per-request",
  "success": true,
  "data": { ... }
}

On failure:

{
  "id": "uuid-v4-per-request",
  "success": false,
  "msg": "human-readable error string",
  "data": null
}

api-v3 returns the envelope as { "id", "success", "data" }. The pump-* services use addBorderSuccess / addBorderErr helpers that produce the same shape with msg populated only on errors. Check each service’s intro page for the exact envelope it uses.

How to use this section

Click any endpoint in the left navigation. You will see:

• The HTTP method, full URL, and base host.
• Request parameters with types pulled from the OpenAPI spec.
• A Try it panel that lets you set parameters and send a real request to mainnet (or pick a devnet server from the dropdown when available).
• The response shape, sourced from a representative live response and the source code’s addBorderSuccess callsite.

For SDK-level access — building transactions client-side, batching swaps, the TypeScript types — see sdk-api/typescript-sdk.

Pointers

• sdk-api/rest-api — narrative overview of the REST surface, written for first-time integrators.
• integration-guides/aggregator — how to use the Transaction API alongside on-chain pools.
• reference/program-addresses — every program ID returned by api-v3 resolves to one of these.