Chaingateway Solana API

A Solana API should not force a JavaScript SDK on your backend. Chaingateway wraps Solana in plain REST: you create addresses and send SPL tokens with two POST requests, and a GET returns the current block height. Authentication is a Bearer token in the Authorization header. Responses are JSON. Your PHP, Go or Java backend talks to Solana the same way it talks to any other HTTP service.

The trial runs 7 days and asks for no KYC. Create an API key and make your first request before the next block lands.

One capability per endpoint

RPC providers structure their Solana documentation by capability: node access here, streaming there, webhooks in a third place. Chaingateway's Solana surface is smaller on purpose, because it is a payments API rather than a general-purpose node service. Mapped the same way, it looks like this:

Capability	Endpoint	Status
Create addresses	POST /api/v2/solana/addresses	Live
Send SOL	POST /api/v2/solana/transactions	Live
Send SPL tokens	POST /api/v2/solana/transactions/SPL	Live
Check balances	GET /api/v2/solana/balances/{address}	Live
Read chain state	GET /api/v2/solana/blocks/number	Live
Deposit webhooks	—	Not on Solana yet; polling pattern below

Every endpoint takes the same Bearer token, and the X-Network: testnet header switches any request to the test environment. Request and response schemas are in the API reference.

Easy transactions

Send SOL and SPL tokens with a simple JSON payload. Solana produces blocks in well under a second, so a payout usually confirms while your user is still looking at the loading spinner.

Secure address handling

Solana addresses are base58-encoded 32-byte public keys, and the API validates them before any transaction is built. The architecture is non-custodial: the keys to your funds belong to you.

Decoded queries

Transaction data comes back as structured JSON instead of base64-encoded blobs. Token transfers are readable without touching raw instruction data.

Webhooks (IPN)

Honesty first: webhooks are not available for Solana yet. Track deposits by polling instead; GET /api/v2/solana/blocks/number tells you when new blocks arrive so you can pace your checks, and GET /api/v2/solana/balances/{address} answers whether anything came in. On Ethereum, BSC, Polygon, Arbitrum, TRON and Bitcoin, deposit webhooks are live today.

Solana over REST, without web3.js

The official route into Solana is JSON-RPC, documented at solana.com/docs/rpc. It exposes the node protocol: methods like getLatestBlockhash and sendTransaction, plus a client library to make them usable. To send an SPL token that way, your code fetches a recent blockhash before it expires, resolves the recipient's associated token account (and creates it when it does not exist yet), then builds, signs and serializes the transaction. In JavaScript, web3.js and the spl-token package do this for you. In every other language, you are largely on your own.

Chaingateway replaces that with one HTTP call. The API resolves token accounts and constructs the transaction server-side, and your backend never imports a Solana SDK. If you want raw chain access for analytics or custom programs, an RPC provider is the right tool. For payments, REST is shorter, and shorter code has fewer places to break.

Mints, token accounts and ATAs: why Solana transfers are different

If you come from Ethereum, BSC or Polygon, the part of Solana most likely to bite you is not speed or fees. It is the account model.

On an EVM chain, a token balance is an entry inside the token contract's own storage. Your address "holds" USDT because the contract's internal table says so. Sending tokens to a brand-new wallet just adds a row to that table; the recipient does not need to exist on-chain in any special way.

Solana splits the same idea into separate accounts. A token is defined by its mint account, which stores supply and decimals. Balances live in token accounts, one per combination of wallet and mint, and the standard variant is the associated token account (ATA): its address is derived deterministically from the wallet address and the mint address. Your wallet does not contain USDC. It owns a separate account that contains USDC.

Two consequences matter for payments. First, an ATA must exist before tokens can land in it. If your recipient has never held the token, the account has to be created on-chain, and creation requires a deposit to make it rent-exempt: 0.00203928 SOL as of mid-2026, per the official Solana documentation. In practice the sender's transaction creates and funds the missing account. Second, transfers move value between token accounts, not between wallet addresses. Code that naively targets the wallet address fails, which is why the SPL transfer instruction takes both token accounts plus the mint and its decimals for verification.

This bookkeeping is exactly what Chaingateway does server-side. You pass wallet addresses and a token mint; the API derives the token accounts and builds a valid transfer. Your backend never learns what a program-derived address is, which is the point.

REST vs. web3.js: the same transfer, twice

Here is what sending 10 USDC looks like with web3.js and the spl-token package:

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
);

And here is the same transfer as a REST call:

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": "EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v",
    "from": "YourSenderAddress",
    "to": "RecipientAddress",
    "amount": 10,
    "privatekey": "YourSenderPrivateKey"
  }'

The JavaScript version is the happy path, and it already juggles connections, PDAs and raw base units (10_000_000 instead of 10). Not shown: handling blockhash expiry when the network is busy, retry logic, and the constraint that this code only runs where you can install JavaScript dependencies. The REST call runs from a PHP 7 monolith as readily as from a fresh Node 22 service. It carries the sender's private key, which signs the transfer, so treat the payload like the keypair file: secrets store, TLS, no logging.

If your backend is JavaScript and you want full control over transaction construction, web3.js is a fine choice with strong documentation. If on-chain code is a means to accepting payments, the comparison is not close.

Quickstart: three requests to your first SPL transfer

Create an address:

curl -X POST https://app.chaingateway.io/api/v2/solana/addresses \
  -H "Authorization: Bearer $CHAINGATEWAY_API_KEY"

Read the current block height, useful as a heartbeat for deposit polling:

curl https://app.chaingateway.io/api/v2/solana/blocks/number \
  -H "Authorization: Bearer $CHAINGATEWAY_API_KEY"

Send an SPL token:

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"
  }'

The same transfer from Python, no Solana dependency in sight:

import os
import requests

r = requests.post(
    "https://app.chaingateway.io/api/v2/solana/transactions/SPL",
    headers={"Authorization": f"Bearer {os.environ['CHAINGATEWAY_API_KEY']}"},
    json={
        "contractaddress": "TokenMintAddress",
        "from": "YourSenderAddress",
        "to": "RecipientAddress",
        "amount": 10,
        "privatekey": os.environ["SOLANA_SENDER_KEY"],
    },
)
print(r.json())

The exact request schema is in the API reference. To run against the test network first, add the header X-Network: testnet and keep everything else identical.

Solana in numbers

Numbers below are checked against the official Solana documentation as of early July 2026.

A slot, the window in which one validator may produce a block, is configured at about 400 milliseconds and fluctuates between roughly 400 and 600 milliseconds in practice. That cadence is why deposit polling every second or two never falls far behind the chain.

The base transaction fee is 5,000 lamports per signature, which is 0.000005 SOL. Half of it is burned, half goes to the block producer. On top of that sits an optional priority fee, priced in micro-lamports per compute unit; it defaults to zero and buys scheduling preference when the network is busy. For a payment workload the practical reading is simple: fees are so small that they disappear inside your margin on even a one-dollar transaction.

Confirmation and finality are different things on Solana, and the distinction matters for how you credit deposits. A transaction is typically confirmed, meaning a supermajority of validators has voted on its block, within a second or two. Full finality takes about 12.8 seconds as of mid-2026. The Alpenglow consensus upgrade, planned for rollout in late 2026, is designed to compress finality to roughly 100 to 150 milliseconds; treat that as an announced plan rather than a live property until it ships. A sensible policy today: credit small payments at confirmation, hold large ones the extra dozen seconds until finality.

Tracking deposits without webhooks

Until webhooks reach Solana, deposit detection is a polling loop, and a disciplined one is cheap to run. Store the block height you processed last. Every second or two, call GET /api/v2/solana/blocks/number; when the number moves, check your deposit addresses with GET /api/v2/solana/balances/{address} — or GET /api/v2/solana/balances/{address}/tokens/{mint} for one specific SPL token — and match anything you find against open orders.

The latency cost is smaller than it sounds. Solana produces blocks in under a second, so even a two-second polling interval means a customer sees "paid" within a few seconds of sending. The whole loop is a few dozen lines in any language and runs as a cron job or a background worker. When you later extend the same flow to a chain with webhooks, the bookkeeping stays identical; only the trigger changes from pull to push.

Accepting USDC on Solana: a worked example

USDC is the payment rail that has made Solana a settlement network, so it makes a concrete walkthrough. The mint address on mainnet is EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v, issued by Circle; anything else claiming to be USDC is not.

The receiving side: when a customer checks out, create a fresh address with POST /api/v2/solana/addresses and store it against the order. Show the address and the amount, and let the customer pay from any wallet or exchange. Your polling loop from the previous section picks up the incoming transfer, matches the receiving address to the order, and flips it to paid. With 400-millisecond slots, the gap between "customer pressed send" and "your database says paid" is a few seconds, most of it your own polling interval.

Record the transaction signature of every credited deposit with a unique constraint. Polling loops get restarted, backfilled and re-run, and idempotency at the database layer means none of that can double-credit an order.

The paying side mirrors it. A payout is one POST /api/v2/solana/transactions/SPL call with the USDC mint as contractaddress and a human-readable "amount": 10; the API applies USDC's six decimals for you. Keep a modest SOL balance on the sending address: 0.000005 SOL per signature for fees, plus 0.00203928 SOL whenever a recipient's token account has to be created. Both amounts are small enough that a single topped-up float covers months of payouts.

What you get over card rails is settlement in seconds with no chargeback mechanism, and what you give up is the ability to reverse a mistake. The address validation the API performs before building a transaction is your friend here, but your own confirmation screen matters just as much.

Send and receive any token on Solana, even your own

SPL is Solana's token standard, and the API treats every SPL mint the same way. USDC and USDT work out of the box, with decimals applied automatically. If you minted your own token, pass its mint address to the same endpoint and it behaves like the majors. Because Chaingateway uses one endpoint structure across chains, the Solana code above ports to Ethereum, BSC or Polygon by swapping the chain segment and the token suffix in the URL: /solana/transactions/SPL becomes /ethereum/transactions/erc20.

Why developers choose Solana

Solana executes transactions in parallel rather than strictly one after another, which is where its throughput comes from. Fees are small enough that paying out tiny amounts stays economical, and confirmation is fast enough that a checkout page can simply wait for it. USDC volume on Solana has turned the chain into a serious settlement network, and developer momentum around it has held up across several market cycles.

Testnet, devnet and the X-Network header

Solana runs two public test clusters, and the names trip people up. Devnet is the everyday sandbox for application developers: free SOL is available from faucet airdrops, and nothing on it has value. Testnet exists mainly for validators and core contributors to exercise new releases under load. If you have used Ethereum's Sepolia, devnet is the closest equivalent in spirit.

With Chaingateway you do not manage cluster URLs at all. Add the header X-Network: testnet to any request and it runs against the test environment; remove it and the identical request is a mainnet call. There is no second API key and no separate account.

Use the test run for the scenarios that hurt on mainnet: a payout to an address that has never held the token (the token-account creation path), a restart of your polling loop mid-stream, and a duplicate submission of the same payout. Each of those takes minutes to rehearse and each is a real incident if you first meet it in production.

When requests fail

The API reports problems as plain HTTP status codes, so nothing about your error handling needs to be Solana-specific.

A 401 means the Bearer token is missing or wrong. Errors in the 4xx range are validation failures, such as an address that does not decode as base58 or a missing field; the JSON body says what to fix, and retrying without changing the payload is pointless. A 429 means you have hit your plan's rate limit; slow down, and pace deposit polling off the block-height heartbeat rather than a tight loop. Plans with higher limits are on the pricing page.

Server errors in the 5xx range are safe to retry for reads. For token sends, be more careful: after a timeout you do not know whether the transfer was broadcast, and Solana has no webhook trail here yet. Check your own records and the address's recent transfers before submitting again, and keep one database row per intended payout so a re-run of your worker cannot send twice.

Log the full response body next to your request. The status codes and error schemas per endpoint are in the API reference.

Built for every use case

The most common pattern is payment acceptance: assign each customer a deposit address, poll for incoming SPL transfers and mark the order paid, with settlement in seconds and fees too small to matter in your margin calculation. The second pattern is wallet operations: platforms that manage deposits and withdrawals for many users through the same handful of endpoints.

The same building blocks handle payout automation for airdrops and token launches, recurring transfers for subscription billing, and cross-border payments where the alternative is a correspondent-bank chain that takes days and skims percentage points.

Integration in four steps

1. Get your API key. Register and the key appears in your dashboard right away. The 7-day trial needs no KYC.
2. Make your first request. The quickstart covers authentication and your first call.
3. Set up deposit tracking. On Solana this means polling on a block-height heartbeat; on the other chains you can switch to webhooks.
4. Go live. Drop the X-Network: testnet header and the same code runs against mainnet.

Frequently asked questions

What is a Solana API?

A service that lets your application read from and write to the Solana blockchain over HTTP, without running a validator or an RPC node yourself. Chaingateway's Solana API is built for payments: address creation, SOL and SPL transfers, balance and block queries, exposed as REST endpoints behind a Bearer token.

What is the difference between REST and JSON-RPC on Solana?

JSON-RPC is the node's native protocol. It is low-level: you submit fully built, signed transactions and interpret raw account data, which in practice requires web3.js or an equivalent library. REST, as Chaingateway implements it, sits a layer above: you describe the transfer in JSON and the server handles construction and broadcasting. JSON-RPC suits explorers and DeFi backends that need every method; REST suits payment systems that need a handful of operations with minimal code.

What is an associated token account?

On Solana, token balances do not live in your wallet address. Each combination of wallet and token mint has its own token account, and the associated token account (ATA) is the standard one, derived deterministically from the two addresses. An ATA must exist and hold a rent-exempt deposit of 0.00203928 SOL (as of mid-2026) before it can receive tokens. Chaingateway derives and, where needed, creates these accounts server-side, so your integration only deals in wallet addresses.

Do I need SOL to send SPL tokens?

Yes, a little. The sending address pays the base fee of 5,000 lamports (0.000005 SOL) per signature, and when the recipient has never held the token, the transaction also funds the new token account with the rent-exempt minimum. A small SOL float on your sending address covers both for a long time.

How fast is a Solana transaction final?

Confirmation, the point where a supermajority of validators has voted on the block, usually arrives within a second or two. Full finality takes about 12.8 seconds as of mid-2026. The Alpenglow upgrade planned for late 2026 targets finality around 100 to 150 milliseconds. For deposits, crediting small amounts at confirmation and large amounts at finality is a reasonable default.

Can I send USDC on Solana with this API?

Yes. Pass the official USDC mint, EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v, as the contractaddress and a decimal amount; the API applies USDC's six decimals automatically. The same call works for USDT or any other SPL mint.

What is the difference between devnet and testnet?

Devnet is Solana's sandbox for application developers, with free SOL from faucets. Testnet primarily serves validators testing new releases. Through Chaingateway you switch to the test environment with the X-Network: testnet header and never handle cluster URLs directly.

Are there rate limits?

Yes, tied to your plan; the current numbers are on the pricing page. For deposit polling, one request per new block is a sensible ceiling, and GET /api/v2/solana/blocks/number is a cheap way to pace that.

Which SPL tokens are supported?

All of them. Any SPL mint works, from USDC and USDT to a token you created yesterday. You pass the mint address in the request, and decimals are handled automatically.

Does the Solana API support webhooks?

Not yet. Webhook notifications are live for Ethereum, BSC, Polygon, Arbitrum, TRON and Bitcoin, but on Solana you track deposits by polling for now. The webhooks guide covers the chains where push notifications are available.

Ready to integrate Solana?

Create your account, copy the API key and send an SPL transfer on the test network in the next ten minutes. The full endpoint reference is at /docs/, and the developer portal has tutorials for the most common payment flows.