Etherscan API V2 Guide
Etherscan API V2 matters because explorer-style reads are still one of the fastest ways to answer product and developer questions across EVM chains. The practical shift is that builders no longer have to swap between per-chain API hosts. The default pattern is one base URL, one API key, and a chainid parameter that tells the request which chain to query.
This page is for teams searching for the Etherscan API V2 base URL, the migration path from older scan endpoints, and the request model needed for account history, contract lookups, logs, and basic multichain workflow design.
Why Etherscan API V2 deserves its own builder guide
The broad Etherscan protocol page is useful for quick registry context, but the search intent behind terms such as etherscan api v2 base url is more operational. Builders landing on this query usually need a request pattern they can implement immediately.
In practice, the decision point is simple: can the team answer multichain EVM data needs with explorer APIs, or does it need a deeper indexing stack? Etherscan V2 is relevant when the answer is still in the lightweight, API-first range.
- a single base URL reduces chain-specific endpoint sprawl
- one API key can serve multiple EVM chains through chainid
- explorer-style endpoints are often enough for account, transaction, and contract lookups
- migration work usually centers on request shape rather than a full architecture rewrite
What changed with the V2 request model
1. One base URL replaces the habit of switching hostnames
The core V2 request target is:
GET https://api.etherscan.io/v2/api?...Instead of routing requests to separate explorer subdomains, builders keep the same base URL and specify the target network in the query string.
2. chainid is now the chain selector that matters first
The practical shape looks like this:
GET https://api.etherscan.io/v2/api
?chainid=8453
&module=account
&action=txlist
&address=0x...
&apikey=$ETHERSCAN_API_KEYThat request pattern is the main concept builders need to internalize. Base useschainid=8453, Arbitrum uses 42161, Optimism uses10, BNB Chain uses 56, Polygon uses 137, and Ethereum mainnet uses 1.
3. One key supports a multichain EVM workflow
Etherscan V2 is designed for teams that want consistent explorer-driven reads across supported EVM networks. The same key can back account history, contract metadata, gas reads, and log queries without forcing the app to maintain a different hostname per chain.
That makes V2 especially useful for products with chain pickers, bridge experiences, portfolio reads, and back-office debugging flows where the user or operator changes networks frequently.
The endpoint workflow builders usually need first
Account history and token movement
The account module is usually where teams begin. It is the quickest path for transaction history, normal transactions, internal transactions, and token transfer lookups tied to a wallet or contract address.
- wallet activity timelines
- deposit and withdrawal checks
- address-level support tooling
- basic token transfer history without custom indexing
Contract inspection and source verification
The contract module helps when a product needs ABI retrieval, source verification context, or fast contract-level reference data. This is often enough for admin tooling, protocol evaluations, or lightweight contract intelligence features.
GET https://api.etherscan.io/v2/api
?chainid=1
&module=contract
&action=getsourcecode
&address=0x...
&apikey=$ETHERSCAN_API_KEYLogs and event-driven reads
The logs module matters when the app needs event-level visibility without running a dedicated indexer yet. Builders typically use it for contract activity windows, transfers by topic, and troubleshooting around protocol events.
When completeness matters, it is safer to query bounded block ranges than to assume one wide request will cover a full historical dataset cleanly.
Gas, blocks, and operational monitoring
Explorer APIs are also useful for small operational reads such as gas oracle data, block references, or transaction receipt-oriented debugging. These calls are often part of support workflows and internal dashboards rather than customer-facing core product paths.
How to migrate from older scan endpoints
Most migrations are not a full rewrite. The main task is normalizing requests around the V2 base URL and making chain selection explicit.
Migration checklist
- 01replace chain-specific hosts with https://api.etherscan.io/v2/api
- 02introduce an explicit chainid value in every request builder
- 03centralize the server-side ETHERSCAN_API_KEY instead of scattering per-chain config
- 04audit pagination assumptions for long histories and logs queries
- 05test the same address workflow across at least two target chains before shipping
Teams that previously hardcoded explorer hostnames usually benefit from creating one small request helper that accepts chainid, module,action, and endpoint-specific params. That reduces repeated migration debt the next time the product adds another supported chain.
Implementation notes that save time later
Keep the key on the server
An explorer key should be treated like shared infrastructure quota, not a browser asset. Proxying requests from the server side protects the key and gives the team a place to add caching, logging, and fallback logic.
Use chain-aware helpers instead of string concatenation everywhere
If the product supports more than one network, the cleanest pattern is one helper that injects chainid and serializes the rest of the request. This prevents chain mismatches and makes internal tooling easier to debug.
Window large history queries
Explorer APIs are convenient, but they are still bounded interfaces. For long histories, it is safer to segment by block range rather than assume simple offset pagination will always cover everything the application needs.
Know when you have outgrown explorer reads
Etherscan V2 is strong for practical explorer workflows, but some products eventually need custom indexing, richer historical transforms, or non-EVM coverage. That is usually the point where teams compare deeper providers such as Alchemy, QuickNode, Goldsky, The Graph, or Covalent depending on the job.
Common Etherscan API V2 mistakes
Treating V2 like a cosmetic version bump
The important change is not the version label. It is the unified request model: one base URL, one key, and an explicit chainid parameter.
Leaving chain choice implicit in application code
A multichain product should pass chainid deliberately through request builders and logs. Hidden defaults make debugging much harder when reads come from the wrong network.
Shipping the API key in client code
Even low-risk explorer reads should be proxied or handled server-side so the key and quota are not exposed to every browser session.
Assuming one large query will cover complete history
For logs and long account histories, bounded block windows are usually safer than relying on a single oversized historical request.
Using Etherscan for workloads that need a real indexing layer
If the app needs custom data models, complex cross-entity joins, or non-EVM support, explorer APIs may stop being the right abstraction.
When builders should choose Etherscan V2 first
- you need a simple explorer API for multiple EVM chains
- the product mainly needs account, contract, logs, or gas-oriented reads
- the team wants a practical migration path away from per-chain scan hosts
- you want to validate demand before investing in heavier indexing infrastructure
If the product is already stretching beyond those needs, the better question is not whether Etherscan V2 works. It is whether the product has outgrown explorer-first reads as the main data layer.
FAQ
What is the Etherscan API V2 base URL?
The unified Etherscan API V2 base URL is https://api.etherscan.io/v2/api. Builders target a specific EVM chain by adding the chainid query parameter instead of switching to a chain-specific hostname.
How do you call Base, Arbitrum, or Optimism with Etherscan V2?
Use the same V2 endpoint and change only the chainid value. For example, chainid=8453 targets Base, chainid=42161 targets Arbitrum, and chainid=10 targets Optimism.
Do legacy per-chain scan endpoints still matter?
For new work, builders should treat the V2 endpoint plus chainid as the standard pattern. Legacy chain-specific endpoints create migration debt because the practical multichain path now centers on the shared V2 request model.
Which Etherscan API V2 modules matter first for builders?
The common starting points are account lookups, logs queries, contract source or ABI reads, gas oracle requests, and block or transaction history endpoints. Together they cover most lightweight explorer-driven workflows.
Should an Etherscan API key stay on the client?
No. Builders should keep the Etherscan API key on the server side and proxy requests as needed. Shipping the key in a client bundle makes quota abuse and key leakage much easier.
When is Etherscan V2 a good fit?
Etherscan V2 is a good fit when a team needs fast explorer-style reads, contract verification data, log lookups, and multichain EVM coverage without standing up its own indexing stack. It is less ideal when the product needs custom historical indexing or non-EVM coverage.
Start with the Etherscan protocol page, then compare your broader data stack
The fastest way to use this guide is to confirm the V2 request pattern here, then jump into the protocol registry entry for the reference details you want in the same workflow. If you are comparing explorer-first and builder-first paths across the site, the TON Connect guide is another example of how web3.new structures practical implementation pages around narrow developer intent.