Blockchain API vs Node: Which One to Use
A blockchain node syncs and stores the full chain. A blockchain API hosts nodes and adds decoded data and webhooks. Costs, trade-offs and when to pick which.
Reviewed by Maurice Sobiera
A blockchain node is software that syncs, validates and stores a blockchain and answers low-level queries about it. A blockchain API is a hosted service that runs nodes for you and returns decoded JSON, often with webhooks. Choose a node for full control and an API to ship payments without running infrastructure.
What do you need to interact with a blockchain?
Any application that reads balances, sends transactions or reacts to deposits needs a connection to a node. Take an exchange deposit: a user sees a Tron address and sends 100 TRX to it. The exchange must learn that the transfer arrived. It can scan every new block itself, or it can ask a service to call it when an address receives funds. Reading a balance works the same way. When you look up an address on a block explorer such as Etherscan, the explorer got that number from a node.
What does it take to run your own node?
You install a client, wait for the initial sync and keep the machine patched, backed up and monitored. The hardware depends on the chain. For Ethereum, the official node documentation lists as minimum 2 CPU cores, 16 GB of RAM, a 2 TB NVMe SSD and 25 Mbit/s of bandwidth (checked on 5 November 2026). Those numbers change with client releases and chain growth, and the page itself notes that the disk requirement will likely be exceeded by 2027. An Ethereum node needs two programs, an execution client and a consensus client (ethereum.org). Other chains have their own requirements: a Bitcoin full node and a Tron full node each need their own client, disk and sync time.
A node returns raw data. On the Ethereum JSON-RPC interface, quantities are hex strings. A balance request returns something like 0x2386f26fc10000, which is 10^16 wei or 0.01 ETH, and your code has to convert it. Token transfers are log entries that you decode with the contract’s ABI.
Detecting deposits is the harder part. Ethereum nodes can push events over a WebSocket subscription, but a dropped connection leaves a gap that you fill by scanning blocks. A scanner you write yourself has to do the following:
- Fetch each new block, or the logs that match the token’s
Transferevent. - Compare the recipient of every transfer with your list of customer addresses.
- Wait for enough confirmations and handle blocks that get replaced in a chain reorganisation.
- Store the last processed block number, so that a restart does not skip blocks.
- Repeat all of this for each chain you support, because each has its own client and data format.
For Tron, the event subscription documentation describes the plug-in route, which you also have to operate.
What does a blockchain API do differently?
It runs the nodes, decodes the data and exposes it as JSON endpoints. With Chaingateway, a webhook replaces the block scan. This request registers a URL that gets called when a given address receives a TRC20 token:
curl -X POST https://app.chaingateway.io/api/v2/tron/webhooks \ -H "Authorization: Bearer $CHAINGATEWAY_TOKEN" \ -H "Content-Type: application/json" \ -d '{ "to": "TWrTTVizHkF3LxTiWE9vCnhWC7CBpNXe22", "url": "https://example.com/hooks/deposit", "type": "TRC20", "reference": "order-1042" }'Webhooks exist for Tron, Ethereum, BNB Smart Chain, Polygon, Arbitrum and Bitcoin. Solana has none, so on Solana you query transactions instead.
What happens when a webhook fails?
Failed notifications are not retried automatically. They appear in a list that you read with GET /api/v2/<chain>/webhooks/notifications/failed. You then call POST /api/v2/<chain>/webhooks/notifications/{id}/retry for each entry. A notification that fails again returns to the list. Each stored notification carries the transaction ID, the type (for example TRC20), the contract address, sender, recipient, block number and the number of attempts.
Two consequences for your receiving server. It has to answer quickly with a success status, and it has to cope with the same event arriving twice, for example after a manual retry. Use the transaction ID as the key for deduplication.
Which one is better: node or API?
Neither wins in general. The table shows where they differ.
| Own node | Blockchain API | |
|---|---|---|
| Setup | Install client, sync, secure the server | Create an account and a token |
| Hardware and upkeep | Yours: disk, patches, client upgrades, monitoring | Provider’s |
| Data format | Raw (hex quantities, encoded logs) | Decoded JSON |
| Deposit notifications | You build them | Webhooks, where the API supports them |
| Control | Full: client version, configuration, no shared limits | Limited to what the API exposes |
| Cost | Servers and engineering time | Plan price, usage-based or monthly |
| Failure handling | Your team | Provider’s infrastructure, but you depend on it |
Choose a node if you need methods an API does not expose, must control the client version, or have regulatory reasons to keep all infrastructure in-house. Choose an API if your product is something else than infrastructure. Teams that already employ blockchain engineers sometimes still use an API for chains they do not specialise in.
How do you start with Chaingateway?
Create an account for the 7-day free trial, which needs no card and no KYC, and use the testnet by adding X-Network: testnet to your requests. Plans start at €49 per month.
Ready to build this yourself? Get your API key — 7-day trial, no card required — or see the Blockchain API for the full endpoint reference.