What Is an RPC Endpoint? A 5-Minute Explainer

You're following your first dApp tutorial. Step one: "paste your RPC endpoint URL here." The code works, the tutorial moves on, and you never find out what that URL actually was — just that nothing runs without it. Then you hit a rate limit, or a tutorial mentions "WebSocket endpoints" and "archive nodes," and the gap in your mental model starts to matter.

This is the five-minute version. By the end you'll know exactly what an RPC endpoint is, how to read the URL, what happens when your code calls one, and when a free public endpoint is fine versus when you need your own.

The one-sentence answer

An RPC endpoint is a URL your code sends requests to in order to read from and write to a blockchain — without running your own node.

That's it. Everything below is just unpacking that sentence.

Why endpoints exist at all

A blockchain is a peer-to-peer network of computers called nodes. Each node stores a copy of the chain and knows how to answer questions about it ("what's the latest block?", "what's this address's balance?") and how to broadcast new transactions.

To interact with the chain, you need to talk to a node. You have two ways to do that: run your own, or borrow someone else's over the internet. Running your own Ethereum node means hundreds of gigabytes of disk, days of initial sync, and ongoing operations. Most developers don't need that — they just need to ask a node questions. An RPC endpoint is a node's question-answering interface, exposed as a URL.

RPC = Remote Procedure Call

"RPC" means Remote Procedure Call: you call a function (a "procedure") that runs somewhere else (it's "remote"). Blockchains standardize this with JSON-RPC — you send a small JSON document naming a method and its parameters, and the node sends a JSON document back.

Here's the most basic call there is — "what's the current block number?" — sent with raw curl:

curl https://rpc.swiftnodes.io/rpc/ethereum?key=YOUR_API_KEY \
  -X POST \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_blockNumber","params":[]}'

The response:

{ "jsonrpc": "2.0", "id": 1, "result": "0x14a2f3b" }

That hex value is the latest block number. Every library you use — viem, ethers, web3.py — is just a friendly wrapper that builds these JSON requests for you and parses the responses.

Anatomy of an endpoint URL

Endpoint URLs look cryptic until you break them into parts:

https://rpc.swiftnodes.io/rpc/ethereum?key=YOUR_API_KEY
└─┬─┘   └──────┬───────┘ └─┬─┘└──┬───┘ └──────┬───────┘
scheme      host          path  chain        API key

• Scheme — https:// for normal request/response, or wss:// for a WebSocket connection (more on that below).
• Host — the provider serving the node (here, SwiftNodes).
• Path / chain — which network you're talking to. Swap ethereum for base, arbitrum, solana, etc., and the same key reaches a different chain.
• API key — identifies your account so the provider can apply your rate limits. Public endpoints often skip this, which is exactly why they're unreliable.

What actually happens on a call

When your code runs getBlockNumber():

1. The library builds the JSON-RPC request (eth_blockNumber).
2. It POSTs that to your endpoint URL over HTTPS.
3. The provider routes it to a healthy node, which reads its local copy of the chain.
4. The node returns the answer as JSON, and the library hands you a clean value.

Here's the same call in the three most common stacks:

// viem
import { createPublicClient, http } from "viem";
const client = createPublicClient({
  transport: http("https://rpc.swiftnodes.io/rpc/ethereum?key=YOUR_API_KEY"),
});
const block = await client.getBlockNumber();

// ethers v6
import { JsonRpcProvider } from "ethers";
const provider = new JsonRpcProvider("https://rpc.swiftnodes.io/rpc/ethereum?key=YOUR_API_KEY");
const block = await provider.getBlockNumber();

# web3.py
from web3 import Web3
w3 = Web3(Web3.HTTPProvider("https://rpc.swiftnodes.io/rpc/ethereum?key=YOUR_API_KEY"))
block = w3.eth.block_number

Different syntax, identical idea: point the provider object at an endpoint URL, then call methods.

Reads vs writes (and why your key stays safe)

Most calls are reads — balances, contract state, logs, the latest block. They don't change anything and don't cost gas.

A write — sending a transaction — is different. Your code signs the transaction locally with your private key, then sends the already-signed transaction to the endpoint via eth_sendRawTransaction. The endpoint only relays it to the network. Your private key never travels to the RPC provider. That's a common worry worth putting to rest: an RPC endpoint is a node interface, not a wallet.

HTTP vs WebSocket endpoints

There are two flavors:

• HTTP (https://) — request/response. You ask, you get one answer. Perfect for one-off reads and sending transactions.
• WebSocket (wss://) — a persistent connection that lets you subscribe to events and have the node push updates to you (new blocks, pending transactions, contract logs) without polling.

If you're building anything real-time — a trading bot, a mempool watcher, a live dashboard — you want WebSocket. We go deeper on that in Solana RPC: WebSocket vs HTTP for high-frequency bots and the WebSocket docs.

Do you actually need a provider?

You have three options, and the right one depends on scale:

Public endpoints are genuinely useful for a first test, but they drop requests under load and can vanish without notice. Running your own node is real infrastructure work. For most projects, a provider is the middle path: you get a reliable, monitored node interface for far less than self-hosting costs, and you skip the ops entirely. (If you're weighing providers, our comparison guide lays out the main ones.)

One concept, every chain

The best part: once you understand one endpoint, you understand all of them. The JSON-RPC pattern is the same across EVM chains, and the URL just changes which network you reach. With a single SwiftNodes key you can hit Ethereum, Base, Arbitrum, Solana, and 70+ others by changing the path — no new account per chain. Non-EVM chains like Solana use their own method names (getSlot instead of eth_blockNumber), but the endpoint concept is identical.

That's the whole model. An RPC endpoint is a URL that lets your code borrow a blockchain node's brain — read state, send transactions, subscribe to events — without running the node yourself. Read the API reference for the full method list when you're ready to go deeper.

SwiftNodes gives you HTTP and WebSocket endpoints across 75+ chains under one key — flat-rate, no KYC, pay with crypto. Grab a free API key and make your first eth_blockNumber call in under a minute.