The Daemon RPC API

Every Monero integration eventually needs to talk to the network: to learn the chain height, estimate fees, look up transactions, and broadcast payments. That conversation happens through the daemon RPC API exposed by monerod, the Monero node software. This is an advanced lesson — you'll be making raw RPC calls — but understanding this layer is the foundation for everything else you build. Crucially, the daemon is the chain, not your wallet: it holds no keys and signs nothing. It reads the blockchain and relays transactions.

Two styles of endpoints

The daemon exposes its functionality in two distinct ways, and it trips up newcomers constantly. The first is JSON-RPC: a single endpoint at POST /json_rpc where you send a JSON body containing a "method" field naming the call you want. The second is the older set of "other" endpoints — each lives at its own path, like POST /get_transactions, POST /send_raw_transaction, and POST /get_transaction_pool. These predate the JSON-RPC interface and some still carry binary-leaning conventions. When you read code or docs and see a bare path, it's an "other" endpoint; when you see a method name, it's JSON-RPC.

A JSON-RPC request looks like this:

{
  "jsonrpc": "2.0",
  "id": "0",
  "method": "get_info"
}

Key JSON-RPC methods

These are the workhorses of the JSON-RPC interface. Use exactly these names:

• get_info — the single most useful call. Returns height, target_height, difficulty, tx_pool_size, status, and synchronized. Poll it to know whether your node is caught up and what the chain tip is.
• get_block and get_block_header_by_height / get_last_block_header — fetch a full block, or just a header by height or for the current tip. Headers carry the hash, timestamp, difficulty, and reward.
• get_fee_estimate — returns a per-byte fee that you multiply by a transaction's weight to compute the fee. Wallets call this so payments aren't under- or over-priced.
• get_outs / get_output_distribution — return output public keys and the distribution of outputs over the chain. These feed ring/decoy selection when a wallet builds a transaction.
• get_height — the bare current height, a lighter call than get_info.
• get_block_count — total number of blocks in the chain.
• on_get_block_hash — look up a block hash given a height.
• sync_info — detailed sync state including connected peers and the heights they report.

A trimmed get_info response:

{
  "height": 3145888,
  "target_height": 3145888,
  "difficulty": 412938472938,
  "tx_pool_size": 17,
  "synchronized": true,
  "status": "OK"
}

The "other" endpoints

The endpoints that matter most for integrations:

• /get_transactions — fetch one or more transactions by hash, and optionally decode them. This is how you pull a transaction's details out of the chain once you know its ID.
• /send_raw_transaction — broadcast a signed transaction blob to the network. You hand it the hex of an already-built, already-signed transaction and the daemon relays it to peers. This is the broadcast step of any payment flow.
• /get_transaction_pool — the mempool: transactions that have been broadcast but not yet mined into a block. Useful for spotting incoming payments before confirmation.
• /is_key_image_spent — check whether given key images have already been spent. Because Monero outputs are hidden, key images are how the network prevents double-spends; this lets you test spent status without revealing amounts.

This layer reads and broadcasts — it does not sign

The single most important mental model: the daemon RPC layer is for reading the chain and broadcasting already-signed transactions. You do not build and sign transactions here by hand. Constructing a transaction — selecting decoys, computing the ring signatures, building range proofs, and signing with your spend key — is the wallet's job, covered in the next lesson. The daemon never sees your private keys, which is exactly why it's safe to point your wallet at a node you don't personally run. The daemon's role in a payment is the final hop: take the signed blob the wallet produced and shout it to the network via /send_raw_transaction.

A concrete integration

Picture a service that accepts Monero. Its daemon interaction is small and well-defined:

• It polls get_info on a timer to track sync status and the current chain height, so it knows how many confirmations a payment has.
• When it needs to send a payout, it calls get_fee_estimate to price the transaction correctly.
• After its wallet builds and signs that payout, the service broadcasts it with /send_raw_transaction.

That's the whole daemon-side story for most apps: watch the chain, estimate fees, broadcast. The cryptographic heavy lifting stays in the wallet.

Restricted vs. unrestricted RPC

Not every node will answer every call. A node started in restricted mode (the default for public RPC, typically on port 18089) exposes only a safe subset of methods — enough for a remote wallet to sync and broadcast, but not enough to abuse the node, leak its peer details, or trigger expensive operations. Your own unrestricted node (port 18081, bound to localhost or your private network) exposes everything, including administrative and diagnostic calls. When you design an integration, decide early whether you'll rely on public restricted nodes or run your own unrestricted one — it determines which methods are available to you and how much you trust the answers.

Where to go next

The full, authoritative list of methods, parameters, and response fields lives in the official Daemon RPC documentation on getmonero.org. Keep it open while you build — the field names and call signatures change between releases, and the docs are the source of truth. Once you're comfortable reading the chain and broadcasting through the daemon, the next step is the component that actually creates and signs transactions: the wallet RPC.

Next: monero-wallet-rpc: The Workhorse