How to fix 403 Forbidden error on RPC endpoint

02 September 2026

You are building a dapp and your RPC calls return a 403 Forbidden error. This is common when using providers like Infura or Alchemy. The same error class often produces a 401 "project ID is required" message first. Understanding the difference between these two codes saves debugging time.

A 401 error means your request lacks valid authentication credentials. The provider literally cannot identify who you are. The fix is straightforward: you need to add your project ID or API key to the request URL. For Infura, the endpoint should look like https://mainnet.infura.io/v3/YOUR_PROJECT_ID. For Alchemy, it is https://eth-mainnet.g.alchemy.com/v2/YOUR_API_KEY. Without that key segment, the provider returns 401.

A 403 error means the provider knows who you are but denies access. This is an authorization failure. The most common cause is your IP address or origin domain not being allowlisted in the provider dashboard. Each major provider has a setting for this. In Infura, you manage "Allowed Origins" per project. In Alchemy, you set "Allowed Origins" and "Allowed IP Addresses" in the app settings. If you are developing locally, your origin might be http://localhost:3000. Many providers block localhost by default. You must explicitly add it to the allowlist.

Browser-based RPC calls from localhost get blocked for security reasons. A provider sees a request from http://localhost and does not know if it is a legitimate local development environment or a malicious script. The provider cannot verify the request's origin because the browser does not send an Origin header for localhost in some configurations. Solution: add http://localhost:3000 (or your exact local port) to the allowlist. Some developers use a proxy server or a browser extension that spoofs the Origin header. That is not recommended. Use the provider's dashboard.

An adjacent error is "chain ID mismatch". This occurs when you switch networks in your wallet or application but the RPC endpoint remains pointed at a different chain. For example, your contract calls Ethereum mainnet, but you are connected to Polygon. The provider returns an error because the chain ID in the request does not match the chain ID expected by the endpoint. Fix: ensure your application code dynamically updates the RPC URL when the user changes networks. Most Web3 libraries have a chainChanged event. Listen to it and rebuild the provider connection.

Warning about leaking API keys. When you put an API key in client-side JavaScript, anyone who opens the browser developer tools can see it. A malicious actor can use your key to make requests, and you get billed. The provider will not distinguish your legitimate traffic from stolen traffic. Do not hardcode keys in frontend code under any circumstance. Use a backend proxy that holds the key and forwards authenticated requests. If you must expose a key in a browser context, restrict it to specific origins in the provider dashboard. This is the only defense.

A 403 error can also appear if you exceed rate limits, but that typically returns 429 Too Many Requests. The articles linked on this site cover that separate problem. For now, check your allowlists first. Then confirm your project ID is correct. Then test the endpoint from a tool like curl, which bypasses browser origin restrictions. If curl works but the browser does not, the issue is almost certainly the origin allowlist.

No live market data exists for starname.me as of August 31, 2026. No chain, contract, or launch date has been found in on-chain queries for "starname." This troubleshooting page applies generically to any RPC provider configuration.

The fix sequence is this: add your project ID to the URL. Add your IP address and browser origin to the provider allowlist. Handle chain ID changes in your dapp code. Never expose keys in client-side code. A 403 error is not a mystery. It is a configuration mismatch. Solve the mismatch, and the error disappears.

Back to rpc & nodes