Solana API: Pagos de SOL y Tokens SPL vía REST
Crea direcciones de Solana y mueve SOL y tokens SPL con simples llamadas REST. Sin web3.js y sin SDK que instalar.
Una Solana API no debería forzar un SDK de JavaScript en tu backend. Chaingateway envuelve Solana en REST simple: creas direcciones y envías tokens SPL con dos solicitudes POST, y un GET devuelve la altura de bloque actual. La autenticación es un Bearer token en la cabecera Authorization. Las respuestas son JSON. Tu backend en PHP, Go o Java habla con Solana de la misma forma en que habla con cualquier otro servicio HTTP.
La prueba dura 7 días y no pide KYC. Crea una API key y haz tu primera solicitud antes de que llegue el siguiente bloque.
Una capacidad por endpoint
Los proveedores de RPC estructuran su documentación de Solana por capacidad: acceso al nodo aquí, streaming allá, webhooks en un tercer sitio. La superficie de Solana en Chaingateway es más pequeña a propósito, porque es una API de pagos y no un servicio de nodo de propósito general. Mapeada de la misma forma, se ve así:
| Capacidad | Endpoint | Estado |
|---|---|---|
| Crear direcciones | POST /api/v2/solana/addresses | Activo |
| Enviar SOL | POST /api/v2/solana/transactions | Activo |
| Enviar tokens SPL | POST /api/v2/solana/transactions/SPL | Activo |
| Consultar saldos | GET /api/v2/solana/balances/{address} | Activo |
| Leer el estado de la chain | GET /api/v2/solana/blocks/number | Activo |
| Webhooks de depósito | — | Aún no disponible en Solana; patrón de polling más abajo |
Cada endpoint toma el mismo Bearer token, y la cabecera X-Network: testnet cambia cualquier solicitud al entorno de pruebas. Los esquemas de solicitud y respuesta están en la referencia de la API.
Transacciones sencillas
Envía SOL y tokens SPL con un payload JSON simple. Solana produce bloques en bastante menos de un segundo, así que un pago suele confirmarse mientras tu usuario todavía mira el indicador de carga.
Manejo seguro de direcciones
Las direcciones de Solana son claves públicas de 32 bytes codificadas en base58, y la API las valida antes de construir cualquier transacción. La arquitectura es non-custodial: las keys de tus fondos te pertenecen a ti.
Consultas decodificadas
Los datos de transacción vuelven como JSON estructurado en lugar de blobs codificados en base64. Las transferencias de tokens son legibles sin tocar datos de instrucción en bruto.
Webhooks (IPN)
Honestidad primero: los webhooks aún no están disponibles para Solana. Rastrea depósitos mediante polling en su lugar; GET /api/v2/solana/blocks/number te dice cuándo llegan bloques nuevos para que puedas ajustar el ritmo de tus comprobaciones, y GET /api/v2/solana/balances/{address} responde si algo llegó. En Ethereum, BSC, Polygon, Arbitrum, TRON y Bitcoin, los webhooks de depósito ya están activos hoy.
Solana vía REST, sin web3.js
La vía oficial hacia Solana es JSON-RPC, documentada en solana.com/docs/rpc. Expone el protocolo del nodo: métodos como getLatestBlockhash y sendTransaction, más una librería cliente para hacerlos usables. Para enviar un token SPL de esa forma, tu código obtiene un blockhash reciente antes de que caduque, resuelve la associated token account del destinatario (y la crea si aún no existe), y luego construye, firma y serializa la transacción. En JavaScript, web3.js y el paquete spl-token hacen esto por ti. En cualquier otro lenguaje, estás en gran medida solo.
Chaingateway reemplaza eso con una llamada HTTP. La API resuelve las token accounts y construye la transacción del lado del servidor, y tu backend nunca importa un SDK de Solana. Si quieres acceso en bruto a la chain para analítica o programas personalizados, un proveedor de RPC es la herramienta correcta. Para pagos, REST es más corto, y el código más corto tiene menos sitios donde romperse.
Mints, token accounts y ATAs: por qué las transferencias en Solana son distintas
Si vienes de Ethereum, BSC o Polygon, la parte de Solana que más probablemente te muerda no es la velocidad ni las comisiones. Es el modelo de cuentas.
El modelo EVM
Un saldo de token es una entrada dentro del almacenamiento propio del contrato del token. Tu dirección "contiene" USDT porque la tabla interna del contrato así lo dice. Enviar tokens a una wallet completamente nueva solo añade una fila a esa tabla; el destinatario no necesita existir on-chain de ninguna forma especial.
El modelo de Solana
Solana divide la misma idea en cuentas separadas. Un token se define por su mint account, que almacena el suministro y los decimales. Los saldos viven en token accounts, una por cada combinación de wallet y mint, y la variante estándar es la associated token account (ATA): su dirección se deriva de forma determinista a partir de la dirección de la wallet y la dirección del mint. Tu wallet no contiene USDC. Es dueña de una cuenta separada que contiene USDC.
Dos consecuencias para los pagos
- Una ATA debe existir antes de que los tokens puedan llegar a ella. Si tu destinatario nunca ha tenido el token, la cuenta tiene que crearse on-chain, y la creación requiere un depósito para hacerla exenta de rent: 0,00203928 SOL a mediados de 2026, según la documentación oficial de Solana. En la práctica, la transacción del remitente crea y financia la cuenta faltante.
- Las transferencias mueven valor entre token accounts, no entre direcciones de wallet. El código que apunta ingenuamente a la dirección de la wallet falla, razón por la cual la instrucción de transferencia SPL toma ambas token accounts más el mint y sus decimales para verificación.
Esta contabilidad es exactamente lo que Chaingateway hace del lado del servidor. Tú pasas direcciones de wallet y un token mint; la API deriva las token accounts y construye una transferencia válida. Tu backend nunca aprende qué es una program-derived address, que es precisamente el objetivo.
REST frente a web3.js: la misma transferencia, dos veces
Así se ve enviar 10 USDC con web3.js y el paquete spl-token:
import { Connection, PublicKey } from "@solana/web3.js";
import {
getOrCreateAssociatedTokenAccount,
transferChecked,
} from "@solana/spl-token";
const connection = new Connection("https://your-rpc-endpoint");
const usdc = new PublicKey("EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v");
const senderAta = await getOrCreateAssociatedTokenAccount(
connection, payer, usdc, payer.publicKey
);
const recipientAta = await getOrCreateAssociatedTokenAccount(
connection, payer, usdc, new PublicKey(recipient)
);
await transferChecked(
connection, payer,
senderAta.address, usdc, recipientAta.address,
payer, 10_000_000, 6 // 10 USDC at 6 decimals
);Una sola llamada en lugar de la contabilidad de ATAs de arriba — crea una cuenta y pruébala en devnet.
Quickstart: tres solicitudes hasta tu primera transferencia SPL
Crea una dirección:
curl -X POST https://app.chaingateway.io/api/v2/solana/addresses \
-H "Authorization: Bearer $CHAINGATEWAY_API_KEY"curl https://app.chaingateway.io/api/v2/solana/blocks/number \
-H "Authorization: Bearer $CHAINGATEWAY_API_KEY"curl -X POST https://app.chaingateway.io/api/v2/solana/transactions/SPL \
-H "Authorization: Bearer $CHAINGATEWAY_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"contractaddress": "TokenMintAddress",
"from": "YourSenderAddress",
"to": "RecipientAddress",
"amount": 10,
"privatekey": "YourSenderPrivateKey"
}'Solana en cifras
Las cifras siguientes están comprobadas contra la documentación oficial de Solana a principios de julio de 2026.
Un slot, la ventana en la que un validador puede producir un bloque, está configurado en unos 400 milisegundos y fluctúa entre aproximadamente 400 y 600 milisegundos en la práctica. Ese ritmo es la razón por la que el polling de depósitos cada uno o dos segundos nunca se queda muy atrás de la chain.
La comisión base de transacción es de 5.000 lamports por firma, lo cual son 0,000005 SOL. La mitad se quema, la mitad va al productor del bloque. Sobre eso hay una comisión de prioridad opcional, con precio en micro-lamports por unidad de cómputo; por defecto es cero y compra preferencia de programación cuando la red está ocupada. Para una carga de trabajo de pagos, la lectura práctica es sencilla: las comisiones son tan pequeñas que desaparecen dentro de tu margen incluso en una transacción de un dólar.
Confirmación y finalidad son cosas distintas en Solana, y la distinción importa para cómo acreditas los depósitos. Una transacción suele estar confirmada, es decir, una supermayoría de validadores ha votado sobre su bloque, en un segundo o dos. La finalidad completa tarda unos 12,8 segundos a mediados de 2026. La actualización de consenso Alpenglow, prevista para finales de 2026, busca comprimir la finalidad a entre 100 y 150 milisegundos aproximadamente; trátalo como un plan anunciado en lugar de una propiedad ya activa hasta que se lance. Una política sensata hoy: acredita los pagos pequeños en la confirmación, retén los grandes esa docena de segundos extra hasta la finalidad.
Rastrear depósitos sin webhooks
Solana todavía no tiene un endpoint de webhook de depósito en la API de Chaingateway. La detección hace polling en su lugar sobre dos llamadas: GET /api/v2/solana/blocks/number para seguir los bloques nuevos y GET /api/v2/solana/balances/{address} para comprobar fondos entrantes. Con slots por debajo del segundo, un intervalo de polling de dos segundos igual muestra un pago como recibido en cuestión de segundos.
Un bucle de polling disciplinado es barato de ejecutar. Guarda la altura de bloque que procesaste la última vez, y cada vez que avance, comprueba tus direcciones de depósito — o GET /api/v2/solana/balances/{address}/tokens/{mint} para un token SPL concreto — y compara lo que encuentres contra los pedidos abiertos.
El coste de latencia es menor de lo que suena. Solana produce bloques en menos de un segundo, así que incluso un intervalo de polling de dos segundos significa que un cliente ve "pagado" a los pocos segundos de enviar. Todo el bucle son unas pocas docenas de líneas en cualquier lenguaje y funciona como un cron job o un worker en segundo plano. Cuando más adelante extiendas el mismo flujo a una chain con webhooks, la contabilidad se mantiene idéntica; solo cambia el disparador, de pull a push.
Aceptar USDC en Solana: un ejemplo resuelto
USDC es el riel de pago que ha convertido a Solana en una red de liquidación, así que da para un recorrido concreto. La dirección del mint en mainnet es EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v, emitida por Circle; cualquier otra cosa que diga ser USDC no lo es.
El lado receptor: cuando un cliente hace checkout, crea una dirección nueva con POST /api/v2/solana/addresses y guárdala junto al pedido. Muestra la dirección y el importe, y deja que el cliente pague desde cualquier wallet o exchange. Tu bucle de polling de la sección anterior recoge la transferencia entrante, empareja la dirección receptora con el pedido, y lo marca como pagado. Con slots de 400 milisegundos, la brecha entre "el cliente pulsó enviar" y "tu base de datos dice pagado" es de unos pocos segundos, la mayor parte tu propio intervalo de polling.
Registra la firma de transacción de cada depósito acreditado con una restricción de unicidad. Los bucles de polling se reinician, se rellenan hacia atrás y se vuelven a ejecutar, y la idempotencia a nivel de base de datos hace que nada de eso pueda acreditar un pedido dos veces.
El lado del pago lo refleja. Un pago es una sola llamada POST /api/v2/solana/transactions/SPL con el mint de USDC como contractaddress y un "amount": 10 legible; la API aplica por ti los seis decimales de USDC. Mantén un saldo modesto de SOL en la dirección remitente: 0,000005 SOL por firma para comisiones, más 0,00203928 SOL cada vez que haya que crear la token account de un destinatario. Ambos importes son lo bastante pequeños como para que un único saldo recargado cubra meses de pagos.
Lo que obtienes frente a los rieles de tarjeta es liquidación en segundos sin mecanismo de contracargo, y lo que renuncias es la capacidad de revertir un error. La validación de direcciones que la API realiza antes de construir una transacción es tu aliada aquí, pero tu propia pantalla de confirmación importa igual de mucho.
Envía y recibe cualquier token en Solana, incluido el tuyo
SPL es el estándar de tokens de Solana, y la API trata cada mint SPL de la misma forma. USDC y USDT funcionan de fábrica, con los decimales aplicados automáticamente. Si acuñaste tu propio token, pasa su mint address al mismo endpoint y se comporta como los principales. Como Chaingateway usa una única estructura de endpoint entre chains, el código de Solana anterior se traslada a Ethereum, BSC o Polygon cambiando el segmento de chain y el sufijo de token en la URL: /solana/transactions/SPL se convierte en /ethereum/transactions/erc20.
Por qué los desarrolladores eligen Solana
Solana ejecuta las transacciones en paralelo en lugar de estrictamente una tras otra, que es de donde viene su rendimiento. Las comisiones son lo bastante pequeñas como para que pagar importes diminutos siga siendo económico, y la confirmación es lo bastante rápida como para que una página de checkout simplemente pueda esperarla. El volumen de USDC en Solana ha convertido la chain en una red de liquidación seria, y el impulso de los desarrolladores en torno a ella se ha mantenido a lo largo de varios ciclos de mercado.
Testnet, devnet y la cabecera X-Network
Solana ejecuta dos clústeres de prueba públicos, y los nombres confunden a la gente. Devnet es la sandbox cotidiana para desarrolladores de aplicaciones: hay SOL gratis disponible mediante airdrops de faucet, y nada en ella tiene valor. Testnet existe sobre todo para que validadores y colaboradores principales pongan a prueba nuevas versiones bajo carga. Si has usado Sepolia de Ethereum, devnet es el equivalente más cercano en espíritu.
Con Chaingateway no gestionas en absoluto las URLs de clúster. Añade la cabecera X-Network: testnet a cualquier solicitud y se ejecuta contra el entorno de pruebas; quítala y la solicitud idéntica es una llamada de mainnet. No hay una segunda API key ni una cuenta separada.
Usa la ejecución de prueba para los escenarios que duelen en mainnet: un pago a una dirección que nunca ha tenido el token (la ruta de creación de token account), un reinicio de tu bucle de polling a mitad de camino, y un envío duplicado del mismo pago. Cada uno de esos toma minutos de ensayo y cada uno es un incidente real si te lo encuentras por primera vez en producción.
Cuando fallan las solicitudes
La API reporta los problemas como códigos de estado HTTP simples, así que nada de tu manejo de errores necesita ser específico de Solana.
Un 401 significa que el Bearer token falta o está mal. Los errores en el rango 4xx son fallos de validación, como una dirección que no decodifica como base58 o un campo ausente; el cuerpo JSON dice qué corregir, y reintentar sin cambiar el payload no sirve de nada. Un 429 significa que has alcanzado el límite de tasa de tu plan; reduce el ritmo, y ajusta el polling de depósitos al latido de la altura de bloque en lugar de a un bucle apretado. Los planes con límites más altos están en la página de precios.
Los errores de servidor en el rango 5xx son seguros de reintentar para lecturas. Para envíos de token, ten más cuidado: tras un timeout no sabes si la transferencia se transmitió, y Solana aún no tiene rastro de webhook aquí. Comprueba tus propios registros y las transferencias recientes de la dirección antes de enviar de nuevo, y mantén una fila de base de datos por cada pago previsto para que una re-ejecución de tu worker no pueda enviar dos veces.
Registra el cuerpo completo de la respuesta junto a tu solicitud. Los códigos de estado y esquemas de error por endpoint están en la referencia de la API.
Construido para cada caso de uso
El patrón más común es la aceptación de pagos: asigna a cada cliente una dirección de depósito, haz polling de las transferencias SPL entrantes y marca el pedido como pagado, con liquidación en segundos y comisiones demasiado pequeñas como para importar en tu cálculo de margen. El segundo patrón son las operaciones de wallet: plataformas que gestionan depósitos y retiros para muchos usuarios a través del mismo puñado de endpoints.
Los mismos bloques de construcción gestionan la automatización de pagos para airdrops y lanzamientos de tokens, transferencias recurrentes para facturación de suscripciones, y pagos transfronterizos donde la alternativa es una cadena de bancos corresponsales que se lleva días y se queda con puntos porcentuales.
Integración en tres pasos
Obtén tu API key. Regístrate y la key aparece en tu panel de inmediato. La prueba de 7 días no necesita KYC.
Haz tu primera solicitud. El quickstart cubre la autenticación y tu primera llamada.
Configura el seguimiento de depósitos y sal a producción. En Solana esto significa hacer polling al ritmo de la altura de bloque; en las demás chains puedes cambiar a webhooks. Una vez que funcione, elimina la cabecera X-Network: testnet y el mismo código se ejecuta contra mainnet.
Qué funciona en cada chain
Solana es la única chain sin webhooks de depósito todavía, de ahí el guion en esa columna más abajo en esta página. Así es como se compara el panorama completo de endpoints entre las siete chains.
| Chain | Direcciones | Transferencias de tokens | Webhooks de depósito |
|---|---|---|---|
| Bitcoin | POST /api/v2/bitcoin/wallets/{wallet}/addresses | — (sin estándar de token) | GET /api/v2/bitcoin/webhooks/notifications |
| Ethereum | POST /api/v2/ethereum/addresses/import | ERC-20: POST /api/v2/ethereum/transactions/erc20 | GET /api/v2/ethereum/webhooks/notifications |
| TRON | POST /api/v2/tron/addresses/import | TRC-20 y TRC-10: POST /api/v2/tron/transactions/trc20 y .../trc10 | GET /api/v2/tron/webhooks/notifications |
| Solana | POST /api/v2/solana/addresses | SPL: POST /api/v2/solana/transactions/SPL | — |
| BNB Smart Chain | POST /api/v2/bsc/addresses/import | BEP-20: POST /api/v2/bsc/transactions/bep20 | GET /api/v2/bsc/webhooks/notifications |
| Polygon | POST /api/v2/polygon/addresses/import | ERC-20: POST /api/v2/polygon/transactions/erc20 | GET /api/v2/polygon/webhooks/notifications |
| Arbitrum | POST /api/v2/arbitrum/addresses/import | ERC-20: POST /api/v2/arbitrum/transactions/erc20 | GET /api/v2/arbitrum/webhooks/notifications |
Dos notas al pie para leer bien la tabla. Primero: TRON es la integración más profunda de la plataforma. Más allá de las rutas anteriores, la documentación cubre staking (POST /api/v2/tron/freeze y /delegate), parámetros de la chain, y un par de auto-firma — /transactions/trc20/build para construir una transacción y /transactions/broadcast para enviar una que hayas firmado localmente. Si tu equipo de cumplimiento insiste en que las private keys nunca salgan de tus servidores, ese patrón de construir y transmitir es tu vía de entrada.
Segundo: un guion significa que la documentación actual no recoge una ruta v2 para esa celda, no que la red sea de segunda categoría. Bitcoin no tiene estándar de token, de ahí la celda de token vacía — el BTC nativo funciona con su propio modelo de wallet en su lugar: crea una wallet cifrada con contraseña con POST /api/v2/bitcoin/wallets, deriva direcciones de depósito bajo ella, y envía con POST /api/v2/bitcoin/transactions. La documentación de Solana cubre creación de direcciones, transferencias de SOL y SPL, y consultas de saldo y bloque, pero aún sin webhooks. Para cualquier cosa no listada aquí, la referencia de la API tiene el estado actual.
Preguntas frecuentes
¿Listo para integrar Solana?
Crea tu cuenta, copia la API key y envía una transferencia SPL en la red de pruebas en los próximos diez minutos. La referencia completa de endpoints está en /docs/, y el portal para desarrolladores tiene tutoriales para los flujos de pago más comunes.