Summary
Alchemy RPC is a hosted JSON-RPC service that connects your application to blockchain nodes without you running the nodes yourself. You create an app in the Alchemy dashboard, receive an HTTPS endpoint (and often a WebSocket endpoint) scoped to a network, and then send standard JSON-RPC calls such as eth_call, eth_getLogs, or eth_sendRawTransaction to that URL. Alchemy also layers product features on top of raw RPC, including enhanced APIs, webhooks, and account tooling.
Most developers searching for "Alchemy RPC" are trying to answer one of three practical questions: how do I get an endpoint and call it, what limits or features come with the hosted service, and is it the right provider for my workload. This page answers those questions in that order, then gives you an evaluation checklist you can apply to Alchemy or any other RPC provider, including OnFinality's RPC API service and dedicated nodes.
One caveat up front: pricing tiers, rate limits, and supported networks change frequently. Treat any numbers you see on third-party blogs as a starting point and confirm current details on the provider's own pricing and documentation pages before you commit.
Key Takeaways
- Alchemy RPC is a hosted JSON-RPC gateway: you get a per-app, per-network URL and call standard Ethereum-style methods against it.
- The endpoint URL is the integration point, so switching providers is usually a config change rather than a code rewrite — if you keep the URL in one place.
- Evaluate any RPC provider on method coverage (archive, trace, logs), transport support (HTTPS vs WebSocket), throughput limits, and how failures are surfaced.
- Hosted RPC is the fastest way to start; dedicated nodes make sense when you need predictable capacity or isolation from noisy neighbors.
- OnFinality offers an RPC API and dedicated node infrastructure across many networks, so you can compare it on the same criteria as Alchemy.
- Always confirm current pricing, rate limits, and network support on the provider's own pages before committing.
How an Alchemy RPC endpoint actually fits into your app
An RPC endpoint is just an HTTP (or WebSocket) URL that accepts JSON-RPC payloads. In an Alchemy setup, you sign up, create an app, pick a network, and Alchemy issues a URL that embeds your API key. Your app then sends requests like eth_blockNumber or eth_getBalance to that URL. The provider handles node operation, syncing, and routing behind the scenes.
That means the integration surface is small. Most libraries — ethers, viem, web3.js, or a raw fetch call — take a URL and a chain ID and do the rest. The practical consequence is that your provider choice is mostly a configuration decision, not an architectural one, provided you keep the endpoint in one place.
- HTTPS endpoint: used for request/response calls such as reads, gas estimation, and transaction submission.
- WebSocket endpoint: used for subscriptions like new blocks, pending transactions, or logs.
- API key: embedded in the URL or sent as a header; treat it as a secret and keep it out of client-side bundles where possible.
- Network selection: each app is typically scoped to one network, so multi-chain apps hold several endpoints.
Quick recommendation: when Alchemy RPC is a reasonable default
If you are prototyping, running a hackathon project, or shipping a small dApp on a major EVM chain, a hosted RPC provider like Alchemy is usually the fastest path. You get an endpoint in minutes, documentation for common methods, and a dashboard for keys and usage.
The decision gets more interesting once you have production traffic. At that point the question is not "does it work" but "does it behave predictably under my workload." Use the checklist below to decide whether to stay on a shared hosted tier, move up within the same provider, or evaluate alternatives such as OnFinality's managed RPC and dedicated nodes.
| Criterion | What to check | Why it matters |
|---|---|---|
| Prototype or small dApp | Free tier limits, supported networks, docs quality | Hosted RPC removes node operations from your critical path while you validate the product |
| Production read traffic | Throughput limits, caching options, multi-region behavior | Read-heavy apps can hit shared limits during traffic spikes |
| Archive or trace queries | Whether archive data and trace/debug methods are included in your plan | Historical balances and transaction tracing often require archive nodes and are frequently gated |
| Real-time features | WebSocket subscription support and connection limits | Live dashboards and bots depend on stable subscriptions, not polling |
| Predictable capacity | Dedicated node options and isolation from other customers | Noisy-neighbor effects are the usual cause of unexplained latency on shared tiers |
A minimal call against an Alchemy-style endpoint
The request shape is standard JSON-RPC, so the same code works against any compliant provider once you swap the URL. The example below uses a placeholder URL; replace it with the endpoint from your provider dashboard.
curl -X POST "$RPC_URL" -H "Content-Type: application/json" -d '{"jsonrpc":"2.0","id":1,"method":"eth_blockNumber","params":[]}'- In viem:
createPublicClient({ transport: http(process.env.RPC_URL) })thenclient.getBlockNumber(). - In ethers:
new JsonRpcProvider(process.env.RPC_URL)thenprovider.getBlockNumber(). - Keep RPC_URL in an environment variable so switching providers is a one-line change.
Where hosted RPC plans usually draw the line
Most hosted RPC providers, Alchemy included, structure plans around compute units or request counts, with method-level weighting. Cheap methods like eth_blockNumber cost little; expensive ones like eth_getLogs over wide block ranges or trace calls cost more. Understanding that weighting matters more than the headline request limit.
The other common boundary is data scope. Archive data, debug/trace APIs, and large log queries are often restricted to higher tiers or require explicit enablement. If your app depends on historical state or transaction tracing, confirm those methods are available on your plan before you build around them.
| Criterion | What to check | Why it matters |
|---|---|---|
| Method | Typical cost profile | Weighted billing means a few heavy calls can dominate your usage |
| eth_blockNumber / eth_chainId | Low weight, usually included everywhere | Health checks and simple reads are rarely the bottleneck |
| eth_getLogs | Range limits and weighting per block span | Indexers and analytics jobs can exhaust quotas quickly |
| debug_traceTransaction | Availability by plan and network | Tracing is expensive and often gated to higher tiers |
| eth_getBalance (historical block) | Archive node requirement | Non-archive nodes cannot answer historical state queries |
Production readiness checklist before you commit
Use this list to compare Alchemy against any alternative on equal footing. It is deliberately provider-neutral so you can apply it to OnFinality's RPC API or dedicated nodes as well.
- Method coverage: confirm archive, trace, and log query support on your target networks.
- Transport: verify WebSocket availability and connection limits if you need subscriptions.
- Failure behavior: know what an overloaded endpoint returns (HTTP 429, JSON-RPC error, or timeout) and how your client retries.
- Observability: check whether the dashboard exposes per-method usage and error rates.
- Failover: decide whether you need a secondary provider or a dedicated node as a backstop.
- Exit cost: keep the endpoint in config so migration is a URL swap, not a refactor.
Migration checkpoints if you switch providers
Because the integration surface is a URL, switching RPC providers is usually straightforward. The risk is in the details: method differences, error formats, and subscription behavior. Run through these checkpoints before cutting over.
- Inventory every RPC method your app calls, including background jobs and indexers.
- Test the new endpoint against your heaviest queries, especially
eth_getLogsranges and trace calls. - Confirm WebSocket subscription behavior and reconnect logic under dropped connections.
- Compare error responses for rate limiting and invalid params so your retry logic still works.
- Run both endpoints in parallel for a period and compare results on the same blocks.
- Keep the old endpoint configured as a fallback until the new one has proven stable in production.
Frequently Asked Questions
Is Alchemy RPC free to use?
Alchemy offers a free tier with usage limits, and paid plans for higher volume and additional features. Exact limits and pricing change over time, so check Alchemy's current pricing page before you plan around a specific tier.
What is the difference between Alchemy RPC and running my own node?
A hosted RPC service like Alchemy operates the nodes, syncing, and availability for you, and you pay per usage or plan. Running your own node gives you full control and isolation but requires ongoing operations, storage, and monitoring work.
Can I use Alchemy RPC with ethers or viem?
Yes. Alchemy endpoints speak standard JSON-RPC, so any library that accepts an RPC URL works. You pass the endpoint URL and chain ID to the library's provider or transport constructor.
Does Alchemy RPC support WebSocket subscriptions?
Alchemy provides WebSocket endpoints for supported networks, which you use for subscriptions such as new heads or logs. Availability and limits depend on your plan and network, so confirm in the dashboard.
How does OnFinality compare to Alchemy for RPC?
Both provide hosted JSON-RPC access. OnFinality also offers dedicated node infrastructure across supported networks, which is useful when you need isolated capacity. Compare them on method coverage, transport support, limits, and pricing for your specific workload.
How do I switch from Alchemy to another RPC provider?
Keep your RPC URL in an environment variable, point it at the new provider's endpoint, and test your heaviest methods before cutting over. Run both endpoints in parallel briefly to catch method or error-format differences.
Ethereum
Solana
Polygon
Base
Arbitrum
BNB Chain
Polkadot
Optimism
