Bitcoin RPC Endpoints & API Access: How Do You Connect to the Bitcoin Network?

Bitcoin's RPC layer works differently from the JSON-RPC interfaces most EVM developers expect. If you are building a wallet, an explorer, a payment processor, or a trading tool, you need to understand which access pattern fits your workload before you pick an endpoint. This page walks through the practical options: Bitcoin Core JSON-RPC, indexed APIs, public endpoints, and managed node services like OnFinality.

Which Bitcoin access pattern fits your workload?

Start by identifying what your application actually needs to do. Bitcoin Core exposes a JSON-RPC interface, but it is designed primarily for node operators and wallet software, not for high-level address queries. Many teams discover this after they try to query an address balance and find that getbalance only returns the balance of the node's own wallet.

Use this table to map your workload to the right access pattern.

If your workload is read-heavy and address-centric, a managed RPC API with indexing is usually the fastest path. If you need full control over node configuration, wallet state, or ZMQ notifications, a dedicated Bitcoin node is the better fit. OnFinality offers both RPC API access and dedicated nodes for supported networks, including Bitcoin.

Bitcoin Core JSON-RPC: what it is and what it is not

Bitcoin Core includes a JSON-RPC server that listens on port 8332 by default for mainnet. It supports a wide range of methods for blockchain data, raw transactions, mempool inspection, and wallet operations. However, it is not a general-purpose indexer. Methods like getblock, getrawtransaction, and gettxout work as expected, but there is no native getAddressBalance or getAddressHistory method.

To query address-level data, you either run an indexer alongside Bitcoin Core (such as Electrum server, Esplora, or a custom index) or use a provider that has already built that indexing layer. This is the single most common source of confusion for developers coming from Ethereum-style RPC.

A basic JSON-RPC request to a Bitcoin node looks like this:

curl --user "rpcuser:rpcpassword" \
  --data-binary '{"jsonrpc":"1.0","id":"onf","method":"getblockchaininfo","params":[]}' \
  -H 'content-type: text/plain;' \
  http://127.0.0.1:8332/

The response includes chain height, verification progress, and softfork status. For a managed endpoint, replace the local URL with the endpoint provided by your infrastructure provider and use the authentication method they specify.

Chain settings and node configuration at a glance

Bitcoin's network parameters are stable, but you should confirm them before connecting any tooling. The table below summarizes the mainnet defaults.

For testnet, the RPC port is 18332 and addresses use different prefixes. If you are testing an integration, use testnet or signet before moving to mainnet. OnFinality's Bitcoin network page lists the supported access options and any testnet availability.

Public endpoints vs managed RPC vs dedicated nodes

Once you know your workload, the next decision is how much infrastructure you want to operate. Public Bitcoin endpoints are useful for quick experiments, but they often rate-limit requests, lack address indexing, and provide no guarantees around availability. Managed RPC providers add authentication, monitoring, and support, while dedicated nodes give you a private instance with custom configuration.

OnFinality's managed RPC API is designed for teams that want a stable endpoint without running a full node. If you need wallet RPC, custom bitcoin.conf settings, or ZMQ block notifications, a dedicated node is the appropriate choice. You can review RPC pricing to compare options based on your expected request volume.

Connecting and authenticating to a Bitcoin RPC endpoint

Bitcoin Core uses HTTP basic authentication by default. When you connect to a managed endpoint, the provider supplies credentials or an API key. The example below shows a generic connection pattern using environment variables, which you can adapt to the credentials from your provider.

const axios = require('axios');

const rpcUrl = process.env.BITCOIN_RPC_URL; // e.g., https://your-endpoint.example.com
const rpcUser = process.env.BITCOIN_RPC_USER;
const rpcPass = process.env.BITCOIN_RPC_PASS;

async function callBitcoinRpc(method, params = []) {
  const response = await axios.post(
    rpcUrl,
    { jsonrpc: '1.0', id: 'onf', method, params },
    {
      auth: { username: rpcUser, password: rpcPass },
      headers: { 'content-type': 'text/plain;' },
    }
  );
  return response.data.result;
}

callBitcoinRpc('getblockcount').then(console.log);

For API-key-based providers, replace the auth object with the required header, such as Authorization: Bearer <token>. Always keep credentials out of client-side code and rotate them if they are exposed.

Common failure modes and how to debug them

Bitcoin RPC errors are usually explicit, but the cause can be non-obvious. The table below maps common symptoms to likely fixes.

If you are using a managed provider, start by confirming that the method you need is supported. Some providers expose only a subset of Bitcoin Core methods. OnFinality's documentation and support channels can confirm method availability for your plan.

When to use a managed Bitcoin RPC provider

A managed provider makes sense when your team wants to focus on application logic rather than node operations. Running a Bitcoin full node requires disk space, bandwidth, initial sync time, and ongoing monitoring. For teams without dedicated infrastructure staff, a managed endpoint reduces operational risk.

OnFinality provides RPC API access and dedicated node infrastructure for a range of networks. For Bitcoin, you can use the managed API for standard JSON-RPC calls, or request a dedicated node if you need custom configuration. Review the supported RPC networks to see availability and RPC pricing for plan details. If you are still evaluating providers, the guide on how to choose an RPC provider covers criteria like method support, failover, and monitoring.

Key Takeaways

• Bitcoin uses JSON-RPC via Bitcoin Core, not EVM-style RPC; address-level queries require an indexer or a provider with indexing.
• Confirm chain settings such as RPC port 8332 for mainnet and address prefixes before connecting.
• Public endpoints are fine for prototypes; managed RPC APIs and dedicated nodes are better for production workloads.
• Authentication is typically HTTP basic auth or an API key; keep credentials server-side.
• Common errors like -32601 and -28 usually point to method availability or sync status.
• OnFinality offers managed RPC API and dedicated node options for Bitcoin; check the Bitcoin network page for details.

Frequently Asked Questions

Does Bitcoin use JSON-RPC?

Yes. Bitcoin Core exposes a JSON-RPC interface for node operations, wallet functions, and blockchain queries. It is not the same as Ethereum's JSON-RPC, and it does not include address indexing by default.

Can I query an address balance with Bitcoin RPC?

Not directly with a standard Bitcoin Core node. You need an indexer or a provider that offers address-level APIs. Some managed services include this indexing layer.

What port does Bitcoin RPC use?

Mainnet uses port 8332 by default. Testnet uses 18332. Managed providers may use HTTPS on port 443.

How do I broadcast a Bitcoin transaction?

Use the sendrawtransaction method with a signed raw transaction hex. The node will validate and relay it to the network.

Is a dedicated Bitcoin node better than a shared endpoint?

It depends on your workload. Dedicated nodes give you full control over configuration, wallet state, and indexing, but require more operational effort. Shared managed endpoints are simpler for standard read and broadcast operations.

Where can I find OnFinality's Bitcoin RPC details?

Visit the Bitcoin network page for supported access options, or review RPC pricing and supported RPC networks.