Saltar al contenido principal

Documentation Index

Fetch the complete documentation index at: https://docs.raydium.io/llms.txt

Use this file to discover all available pages before exploring further.

Esta página fue traducida automáticamente por IA. La versión en inglés es la fuente autorizada.Ver versión en inglés →
La documentación a nivel de endpoint vive en la pestaña API Reference. Cada endpoint tiene un panel interactivo Try it impulsado por el playground de OpenAPI de Mintlify — completa los parámetros en el navegador y accede directamente a mainnet en vivo (o devnet, donde esté disponible). Esta página es el acompañamiento narrativo: qué servicios existen, cuándo usar cada uno, y las convenciones que abarcan todos ellos. Si buscas “¿qué acepta GET /pools/info/ids?”, haz clic en API Reference; si buscas “¿qué servicio debo integrar?”, continúa leyendo.

​
Los once servicios de un vistazo

Raydium ejecuta once servicios HTTP públicos. Cada uno está documentado como su propio grupo en la pestaña API Reference y cuenta con una especificación OpenAPI que respalda el playground interactivo.
ServicioHost MainnetHost DevnetQué proporciona
API v3api-v3.raydium.ioapi-v3-devnet.raydium.ioAPI de lectura canónica para pools / mints / config / chain-info. La puerta de entrada predeterminada para la UI y la mayoría de integradores.
Transaction APItransaction-v1.raydium.iotransaction-v1-devnet.raydium.ioConstrucción de transacciones de swap del lado del servidor.
Perps APIapi-perp-v1.raydium.io—Configuración, metadatos de activos, selección de RPC para la interfaz de Raydium Perps.
LaunchLab Mint APIlaunch-mint-v1.raydium.iolaunch-mint-v1-devnet.raydium.ioBúsqueda de tokens, índices, tablas de clasificación, metadatos por mint.
LaunchLab History APIlaunch-history-v1.raydium.iolaunch-history-v1-devnet.raydium.ioHistorial de transacciones y agregados de velas OHLC para pools de LaunchLab.
LaunchLab Forum APIlaunch-forum-v1.raydium.iolaunch-forum-v1-devnet.raydium.ioHilos de comentarios y cargas IPFS en lanzamientos de LaunchLab. Firmado por wallet.
LaunchLab Auth APIlaunch-auth-v1.raydium.iolaunch-auth-v1-devnet.raydium.ioEmite JWTs ray-token de corta duración a partir de un mensaje firmado por wallet. Requerido por Forum.
Dynamic IPFS APIdynamic-ipfs.raydium.iodynamic-ipfs-devnet.raydium.ioRegeneración de imágenes / metadatos para NFTs dinámicos (posiciones CLMM, etc.).
Owner APIowner-v1.raydium.ioowner-v1-devnet.raydium.ioPosiciones, saldos y recompensas reclamables por wallet.
API v1 (legacy)api.raydium.io—Rutas /v1 y /v2 heredadas mantenidas vivas para clientes que no han migrado a API v3.
Temp APItemp-api-v1.raydium.iotemp-api-v1-devnet.raydium.ioAlmacén para endpoints ad hoc de corta duración. La superficie puede cambiar sin previo aviso.
El versionado vive en el nombre de host para los servicios v3 / v1 — no hay versionado adicional a nivel de ruta. Los cambios que rompen compatibilidad se distribuyen como un nuevo host con solapamiento; el equipo se ha comprometido públicamente con al menos 6 meses de solapamiento en cualquier migración v3 → v4.

​
Elige un servicio

Si quieres…Usa
Leer metadatos de pools, precios, APRs, configuraciones de comisionesAPI v3
Leer metadatos de mints (nombre, símbolo, logo, decimales, etiquetas de riesgo)API v3 /mint/list, /mint/price
Construir una transacción de swap / agregar liquidez / remover liquidez del lado del servidorTransaction API
Mostrar las posiciones de una wallet (tokens LP, posiciones CLMM, apuestas de granja)Owner API
Buscar tokens de LaunchLab, explorar tablas de clasificación, obtener metadatos por mintLaunchLab Mint API
Renderizar un gráfico de velas / candlestick para un pool de LaunchLabLaunchLab History API
Publicar o leer comentarios en un lanzamiento de LaunchLabLaunchLab Auth API → ray-token → LaunchLab Forum API
Renderizar una imagen de NFT de posición CLMMDynamic IPFS API
Mostrar configuraciones de mercados de futuros o listas de activos para la UI de PerpsPerps API
Mantener compatibilidad con un cliente con rutas prefijadas v1/v2API v1 (legacy)

​
Convenciones transversales

​
Envoltura de respuesta

Todos los servicios excepto IPFS devuelven la misma envoltura JSON: 
{
  "id":      "uuid-v4-por-solicitud",
  "success": true,
  "data":    { ... }
}
En caso de error: 
{
  "id":      "uuid-v4-por-solicitud",
  "success": false,
  "msg":     "cadena de error legible para humanos",
  "data":    null
}
Algunos servicios incluyen además un entero error.code (API v3 lo usa para identificadores de error estables en versiones menores). Consulta la página de descripción general de cada servicio para conocer la forma exacta.

​
Autenticación

Aparecen dos patrones:
  • Sin autenticación — todos los servicios excepto Forum. Accede a ellos de forma anónima sobre HTTPS.
  • Handshake firmado por wallet — requerido por LaunchLab Forum API. Firma un mensaje ed25519 de Solana de la forma time:<unix-segundos> con tu wallet, envía la firma + dirección de wallet a LaunchLab Auth API /request-token, recibe un JWT de vuelta, y pásalo como encabezado de solicitud ray-token en llamadas subsecuentes al foro.
El playground de Mintlify acepta ray-token en el panel de autenticación antes de enviar solicitudes al foro; el valor se mantiene solo en tu navegador.

​
Límites de velocidad

Todos los hosts están detrás de Cloudflare con límite de velocidad progresivo por IP de origen. Orientación publicada para integradores: Los estallidos por encima de los límites publicados devuelven HTTP 429 con un encabezado Retry-After. Los agregadores o bots que necesitan límites más altos deben contactar al equipo de Raydium en lugar de atacar los hosts públicos — ejecutar tu propio indexador contra los IDs de programas on-chain también es una opción para cargas de trabajo con muchas lecturas.

​
Caché y consistencia

  • La mayoría de los endpoints de lectura de API v3 se cachean en el borde durante 5-60 segundos; los TTLs específicos se anotan en la página de API Reference de cada endpoint.
  • El caché se invalida por el indexador en eventos que afectan el programa que observa.
  • Durante grandes reorganizaciones o congestión, puede haber una divergencia de 1-2 slots entre la vista de la API y el estado on-chain. El SDK y las lecturas directas de RPC siempre son más actuales — si un cliente está a punto de firmar una transacción, vuelve a recuperar las cuentas relevantes vía RPC, nunca confíes en un valor de API a ciegas.

​
Formato de error

Los errores vuelven como HTTP 4xx/5xx con la misma envoltura (success: false, msg poblado). API v3 además incluye un error.code estable: 
{
  "id":      "uuid-v4-por-solicitud",
  "success": false,
  "msg":     "Pool no encontrado",
  "error":   { "code": 40401, "message": "Pool no encontrado" }
}
El error.code es estable en versiones menores de la API; trátalo como la señal principal en la lógica del cliente y msg como la superficie legible para humanos.

​
Convención de argumentos de par de mints

Muchos endpoints de API v3 aceptan mint1=…&mint2=… y requieren mint1 < mint2 (orden de bytes de clave pública ascendente). Esto permite que la API devuelva el mismo pool canónico independientemente del orden de argumentos preferido por el llamador. Ordena los dos mints del lado del cliente antes de construir la URL — la documentación a nivel de endpoint en API Reference repite esta restricción donde aplica.

​
Patrones de cliente recomendados

  1. Hidrata una vez, actualiza con pereza. Extrae GET /main/info y GET /mint/list (ambos en API v3) al cargar la aplicación y cachea localmente con un TTL de 1 hora. Ambos están altamente cacheados en el borde y rara vez cambian.
  2. Agrupa donde el endpoint lo permita. GET /pools/info/ids?ids=… acepta una lista separada por comas — obtén diez pools en una solicitud, no diez solicitudes.
  3. Evita búsquedas de precios en ruta activa. GET /mint/price está bien para renderizado de UI; nunca lo hagas en bucle en un bot. Para bots de trading, ejecuta un indexador o suscríbete directamente a eventos programSubscribe de RPC.
  4. Refleja o proxy para alto rendimiento. Cualquier cosa por encima del techo de límite de velocidad publicado debe servirse desde tu propia capa de caché, no directamente de los hosts públicos. Los agregadores con >120 req/min sostenido contra transaction-v1 deberían ejecutar su propio motor de cotización / ruta.
  5. Vuelve a obtener justo antes de firmar. Las respuestas de API pueden estar 5-60s desactalizadas. Para una instantánea de pool realmente correcta en el momento de la firma, vuelve a leer las cuentas relevantes vía SDK o una llamada directa de RPC getMultipleAccounts. Trata los valores de API como una pista de búsqueda, no como fuente de liquidación.
  6. Usa Transaction API para integración sin fricciones. Si no quieres agrupar el SDK en tu cliente (nativo móvil, bot en un entorno restringido), Transaction API devolverá una transacción versionada codificada en base64 para que el usuario firme. El swapResponse que devuelve incrusta una cotización — trátala como válida por ~30 segundos.

​
Dónde ir después

  • Referencia de endpoints (interactiva) — API Reference. Cada servicio tiene su propio grupo; haz clic en cualquier endpoint para parámetros, forma de respuesta, ejemplos de código, y un panel Try-it.
  • SDK de TypeScript — sdk-api/typescript-sdk. El SDK consume API v3 internamente para varias rutas; para construcción de transacciones siempre vuelve a obtener estado de RPC, nunca confía en la API a ciegas.
  • Integración de Trade API — integration-guides/aggregator. Patrones para conectar liquidez de Raydium en un agregador multi-DEX.
  • Docs amigables con IA — sdk-api/ai-integration. Punteros para agentes de codificación IA que necesiten llamar estas APIs.