Saltar al contenido principal
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 →
El API de Trading es un conjunto delgado de endpoints en transaction-v1.raydium.io (y algunas rutas espejadas en api-v3.raydium.io) que cotizan un swap, construyen una transacción de Solana lista para firmar y la devuelven en un viaje redondo. Es la misma superficie que usa la interfaz de Raydium. Úsalo cuando quieras enrutamiento de Raydium sin incluir el SDK de TypeScript — backends, manejadores de Blinks, bots de Telegram, aplicaciones de terceros.

Cuándo usar el API de Trading frente al SDK

El SDK es más rico; el API de Trading es más simple. Ambos envuelven los mismos programas CPMM/CLMM/AMM v4 subyacentes, por lo que el swap en cadena resultante es idéntico.

Los tres endpoints

1. GET /compute/swap-base-in

Dado un monto de entrada, selecciona una ruta y devuelve una cotización.
Respuesta:
El campo id es un manejador de cotización opaco pasado al siguiente endpoint. La cotización es estable durante ~30 segundos; después de eso, vuelve a cotizar.

2. GET /compute/swap-base-out

Forma invertida: “Quiero recibir exactamente N de la salida; cótame la entrada requerida”.
Forma de respuesta simétrica a swap-base-in; la semántica del campo amount se invierte.

3. POST /transaction/swap-base-in y /transaction/swap-base-out

Toma la cotización del paso 1 y devuelve una transacción con versión lista para firmar:
Respuesta:
Se pueden devolver múltiples transacciones si el swap requiere configuración (p. ej., crear ATAs, envolver SOL). Firma y envía en orden.

Ejemplo mínimo de extremo a extremo (Python)

Son ~20 líneas. Lo equivalente con el SDK de TS son ~30 pero te da un control más rico (selector de ruta personalizado, presupuesto de unidad de cómputo por pool, metadatos de error detallados).

Enrutamiento y selección de pool

El API de Trading enruta a través de todos los programas de Raydium (CPMM, CLMM, AMM v4) y elige la mejor ejecución para el tamaño cotizado. Características:
  • Saltos múltiples soportados. Un swap SOL→USDC puede enrutarse a través de wSOL→JUP→USDC si eso es más barato.
  • División de múltiples pools del mismo programa no soportada. Una única cotización va a través de exactamente un camino; si deseas dividir tamaño entre pools, hazlo del lado del cliente (dos cotizaciones, dos txs).
  • Estable vs concentrado. El enrutador prefiere usar CLMM cuando la liquidez en rango es adecuada, recurriendo a CPMM para pares de cola larga.
  • Inclusión de AMM v4. Los pools de AMM v4 se incluyen en el enrutamiento pero solo se eligen cuando ofrecen mejor precio que las alternativas CPMM/CLMM.
Para forzar el enrutamiento a través de un pool específico, usa el SDK en su lugar — el API de Trading no expone un parámetro de fijación de pool.

Parámetro de referidor

Añade &referrer=<wallet_pubkey> al endpoint de cómputo para tomar un corte de referencia del 1% en el swap. Consulta user-flows/referrals-and-blinks para la semántica. Cuando está presente:
  • referrerAmount en la respuesta de cotización es la cantidad absoluta (en mint de entrada) que se enrutará al referidor.
  • La transacción final contiene una transferencia extra de token SPL a la ATA del referidor.

Tarifas de prioridad

computeUnitPriceMicroLamports en la solicitud de construcción establece la tarifa de prioridad para la transacción devuelta. Regla general:
  • 50_000 (0.00005 lamports/CU × 200k CU ≈ 0.00001 SOL): mínimo, bien para momentos sin congestión.
  • 200_000: congestión moderada.
  • 1_000_000: congestión pesada.
Para ajuste adaptativo, llama a getRecentPrioritizationFees en tu RPC primero y pasa la mediana. Consulta integration-guides/priority-fee-tuning.

Versiones de transacción

  • "V0" devuelve una transacción con versión (MessageV0) con una tabla de búsqueda para cuentas comunes. Más pequeña, más rápida. Recomendada.
  • "LEGACY" devuelve una transacción heredada. Más grande; solo úsala si tu cartera/infraestructura no maneja V0.

Formas de error

El API devuelve HTTP 200 con success: false para errores lógicos, HTTP 4xx/5xx para errores de transporte / infraestructura. Errores lógicos comunes:
  • "No route found" — sin camino entre los dos mints en este tamaño. Reduce amount o reconsideran el par.
  • "Insufficient liquidity" — existe una ruta pero rebasaría slippageBps. Amplía el slippage.
  • "Quote expired"swapResponse tiene >30s. Vuelve a cotizar.
  • "Unsupported mint" — mint no está en el universo de Raydium (sin listar, o en un programa deprecado).

Límites de velocidad

  • Endpoints de cotización: 120 req/min por IP.
  • Endpoints de construcción: 60 req/min por IP (costo más alto en el servidor).
  • Exceder límites devuelve HTTP 429 con encabezado Retry-After.
Para mayor rendimiento, contacta a las relaciones de desarrolladores de Raydium; hay claves de nivel agregador disponibles.

Patrón arquitectónico para integradores

Todo es sin estado — la única cosa que necesitas enhebrar entre la llamada de cotización y la llamada de construcción es el cuerpo de respuesta de la cotización.

Dónde ir a continuación

  • sdk-api/typescript-sdk — interfaz programática más rica con los mismos programas subyacentes.
  • sdk-api/rest-api — endpoints del lado de lectura (información de pool, información de mint) para complementar el lado de escritura del API de Trading.
  • user-flows/swap — flujo de swap de interfaz de extremo a extremo.
  • integration-guides/aggregator — patrón para agregadores que enrutan a través de muchos DEXes.
Fuentes:
  • Endpoints en vivo de transaction-v1.raydium.io.
  • Inspección de pestaña de red de la interfaz de Raydium (misma superficie consumida).