Bitcoin
Bitcoin
¿Listo para usar esto en producción?
El plan gratuito cubre proyectos personales. El pago por uso escala sin necesidad de tarjeta.
Bitcoin
El plan gratuito cubre proyectos personales. El pago por uso escala sin necesidad de tarjeta.
This page walks through the Bitcoin operations developers reach for first: reading chain state and the tip, fetching blocks, looking up and decoding transactions, checking unspent outputs, estimating fees, validating addresses, and broadcasting a signed transaction — all against https://bitcoin.therpc.io/YOUR_API_KEY. One thing to internalize up front: Bitcoin uses the UTXO model, not accounts. There is no "balance of an address" call, no nonce, and no contract state. The ledger is a set of unspent transaction outputs (UTXOs), each locked to a script; spending consumes whole outputs and creates new ones. To learn what an address controls, you index its outputs yourself or read individual UTXOs with gettxout.
Two reads anchor everything else: overall chain info and the current tip height. getblockchaininfo returns the full picture in one call — which chain you're on (main, test, signet, or regtest), the current blocks height, the best block hash, the difficulty, and verificationprogress toward a fully synced state. When you only need the height, getblockcount returns the tip's block number directly, which is the lightweight call to poll when watching for new blocks.
Blocks are addressed by hash, so reading a block by height is a two-step move: call getblockhash with the height to get its hash, then pass that hash to getblock. The second argument to getblock is a verbosity level that trades detail for response size: 1 returns the header fields plus the list of txids; 2 returns full transaction objects along with each transaction's fee; and 3 adds prevout details for each input (the outputs being spent). Use 1 to walk the chain cheaply and step up to 2 or 3 only when you need transaction or input detail, since the higher levels are heavier reads.
To fetch a transaction by txid, call getrawtransaction with the second argument true (verbose) — instead of a raw hex string you get a decoded object with inputs, outputs, and amounts. Once the transaction is mined, the result also carries confirmations and blockhash, so you can tell at a glance whether and how deeply it's buried. One caveat of the UTXO model: a node only keeps every historical transaction indexed if it runs with -txindex. If a confirmed-but-old transaction can't be found by txid alone, pass its blockhash as a third argument so the node knows which block to look in. TheRPC's Bitcoin endpoint runs with transaction indexing enabled, so plain txid lookups work for historical transactions.
gettxout reads a single output straight from the live UTXO set, identified by its txid and its vout index (the position of the output within that transaction, starting at 0). If the output is still unspent, you get back its value, its scriptPubKey, and the number of confirmations. If the result is null, the output has already been spent or never existed — this is a normal, expected outcome, so branch on it rather than treating it as an error. The returned value is denominated in BTC, not satoshis; multiply by 1e8 if you need the satoshi amount.
estimatesmartfee takes a target confirmation window — the number of blocks you're willing to wait — and returns a feerate in BTC per kilo-virtual-byte (BTC/kvB) the node thinks will get you confirmed within that window. To convert to the sat/vB unit wallets usually display, multiply that feerate by 1e5 (1 BTC/kvB = 100,000,000 sat ÷ 1,000 vB = 100,000 sat/kvB → 100 sat/vB). validateaddress checks whether a string is a well-formed Bitcoin address and, for valid ones, returns its scriptPubKey and address type (such as pubkeyhash, scripthash, or witness_v0_keyhash) — all without any wallet, since it only parses and classifies the address.
getmempoolinfo reports the current state of the node's mempool: how many transactions are pending (size), how much memory they occupy, and the mempoolminfee — the minimum relay fee rate a transaction must pay right now to be accepted. To submit a transaction, sendrawtransaction takes a fully signed raw transaction as hex, relays it to the network, and returns its txid. This method neither funds nor signs anything — you build, fund, and sign the transaction with your own keys client-side; TheRPC's server never sees a private key. Before broadcasting, you can dry-run acceptance with testmempoolaccept, which tells you whether the signed transaction would be accepted (and why not, if it would be rejected) without actually relaying it — useful for catching low-fee or invalid transactions before they hit the network.
rpc(method, params) helper over fetch or axios, as shown in the Quick Start.requests, or use the thin python-bitcoinrpc client where the API key lives in the connection URL.net/http and encoding/json; no Bitcoin SDK is needed.https://bitcoin.therpc.io/YOUR_API_KEY directly for quick checks.