Multi-Blockchain Integration with a REST API

Multi-blockchain integration means that one backend talks to several chains through a single interface instead of one client library per chain. With Chaingateway you call REST endpoints with a bearer token. The same pattern covers Ethereum, BNB Smart Chain, Polygon, Arbitrum, Tron, Bitcoin and Solana, within the limits that each chain sets.

Which blockchains and token standards does the API cover?

The API covers seven chains, each with a testnet. Switch to the testnet with the header X-Network: testnet. The supported networks page lists the test networks. Token transfers have one endpoint per chain:

Every path starts with /api/v2/<chain>/. The full list is in the OpenAPI file.

How do you build a deposit and withdrawal service on it?

A custody-style flow has three parts: an address per customer, a webhook per address, and a withdrawal call. Each part is one request, and each part has the same shape on every chain that supports it.

1. Create a deposit address. On EVM chains and Tron this is POST /api/v2/<chain>/addresses, and the response contains the address. Pass a password so that the key is stored encrypted. Without a password, the response contains the private key and you must store it yourself.
2. Register a webhook for the address. POST /api/v2/<chain>/webhooks takes the receiver url, the address in to, a type such as ERC20 or TRC20, and optionally a contractaddress and a reference of up to 255 characters.
3. Pay out. A withdrawal of an ERC20 token is one request:

curl -X POST https://app.chaingateway.io/api/v2/ethereum/transactions/erc20 \
  -H "Authorization: Bearer $CHAINGATEWAY_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "from": "0xHotWalletAddress",
    "to": "0xCustomerAddress",
    "contractaddress": "0xTokenContract",
    "amount": 100,
    "password": "hot-wallet-password"
  }'

On BNB Smart Chain, replace ethereum/transactions/erc20 with bsc/transactions/bep20. On Tron, use tron/transactions/trc20, which takes the same fields apart from the gas settings. Solana is different: solana/transactions/SPL requires the sender’s privatekey and does not accept a wallet password. The article on personal secrets explains how to verify the notifications you receive.

What happens when a request fails?

The API returns a JSON body with status, ok and message. A 401 with the message “Wrong password provided” means the wallet password does not match. A 422 carries the node’s own error, for example insufficient funds for gas * price + value. The chain-specific part is the reason: an ERC20 transfer on Ethereum needs ETH for gas on the sender address, and a TRC20 transfer needs energy and bandwidth or TRX to burn. Check balances before you retry, because a retry does not fix a missing fee.

Failed webhook notifications are not resent automatically. List them with GET /api/v2/<chain>/webhooks/notifications/failed and resend each with the retry endpoint. A resent notification can arrive after others, so make the receiver idempotent on txid.

What stays different between chains?

Several things stay different, and the API does not hide them:

• Fees: Ethereum, BNB Smart Chain, Polygon and Arbitrum use gas, with a gasprice endpoint for each. Tron uses energy and bandwidth.
• Webhooks: all chains except Solana.
• Wallets: Bitcoin works with named wallets that hold several addresses, created by POST /api/v2/bitcoin/wallets.
• Assets: the same token on two chains is two separate assets, and the API does not bridge between them.

Which chain should you start with?

Start with the chain your customers already use, and add others by reusing the same handlers. Exchange withdrawal forms label the network, for example ERC-20, BEP-20 or TRC-20. Ask your first customers which network they hold USDT on before you build the second integration.

What should you store per chain?

A multi-chain service needs the chain in every record, because the same string can be valid on several chains. Keep at least these fields:

Add a unique constraint on (chain, network, txid). Reconcile against a second source on a schedule, for example the failed-notification list and a block explorer.

How do you start?

Start on testnets. Create an address on Sepolia and one on Nile, register a webhook for each, send a test transfer, and check that your receiver handles both notifications. The 7-day free trial needs no card and no KYC.