Quicknode provides Error Logs for your RPC endpoints. Easily identify and resolve issues by viewing detailed error information directly from your dashboard.
How to read an RPC error
RPC failures are reported at two layers. HTTP errors indicate the request was rejected at the transport level—check for authentication, rate limits, payload size, or service availability. JSON-RPC errors mean the server received the request but couldn't complete the operation—read the error.code, message, and data fields together since codes can vary between node implementations.
- Check the HTTP status to rule out transport issues
- If the status is 200, look at
error.codein the response body - Read the
messageanddatafields for details - For persistent issues, review your Endpoint Logs
HTTP Error Codes
Let's look at the common HTTP Error Codes you can encounter, what they mean and what you can do to prevent them.
#
The endpoint rejected the HTTP request before it could process a normal RPC call.
Diagnose and resolve
Why it happens
- Malformed JSON, an invalid request body, or an unsupported HTTP request format.
- Using the wrong HTTP method or omitting the application/json content type.
- A request to a marketplace add-on or paid API that is not enabled for the endpoint can also return 400.
How to identify it
- Confirm that the HTTP status is 400, then read the response body for the parser or validation message.
- In Endpoint Logs, compare the recorded request method and body with the documented RPC request.
- For an add-on request, check the response message and confirm that the add-on is enabled for this endpoint; providers can use 400 rather than 403 for unavailable access.
How to resolve it
- Serialize the body with a JSON library and send the RPC request with POST and Content-Type: application/json.
- Validate that jsonrpc is "2.0", method is a string, params is an array or object, and id is valid.
- If the request requires an add-on, enable it for the endpoint and verify that the endpoint network is supported before retrying.
#
The request did not satisfy the authentication requirements configured for the endpoint.
#
The endpoint understood the request but refused to authorize it.
Diagnose and resolve
Why it happens
- An endpoint security rule denied the request, or the endpoint is disabled.
How to identify it
- Read the response message and inspect the matching Endpoint Log before changing credentials.
- Check IP allowlists, origin restrictions, method allowlists, and endpoint status.
How to resolve it
- Update the security rule only if the caller should be authorized; otherwise keep the request blocked.
- Re-enable the endpoint or contact support when the dashboard does not explain why it is disabled.
#
The custom trace code is not whitelisted for this endpoint.
Diagnose and resolve
Why it happens
- The trace code has not been approved through the Quicknode approval process.
- The trace method requires a specific add-on or plan that is not enabled.
How to identify it
- Confirm the 403 status and check if the error message mentions custom trace or whitelisting.
How to resolve it
- Submit a support ticket to request approval for the custom trace code.
- Verify that your plan supports custom tracing and the required add-on is enabled.
#
The HTTP route does not exist. An unknown JSON-RPC method normally appears as RPC error -32601 instead.
Diagnose and resolve
Why it happens
- A mistyped endpoint hostname, tokenized URL, path, or add-on route.
How to identify it
- Confirm that this is an HTTP 404 rather than a JSON-RPC response whose error code is -32601.
How to resolve it
- Copy the endpoint URL from the dashboard and verify any required REST or add-on path.
#
The request body is larger than the endpoint accepts.
Diagnose and resolve
Why it happens
- An oversized JSON-RPC batch or a request containing too much encoded data.
How to identify it
- Confirm the 413 HTTP status and measure the serialized request body, not only the number of application objects.
How to resolve it
- Split large batches into smaller requests and reduce unnecessary request data.
#
A request, connection, method, or add-on rate limit was reached.
Diagnose and resolve
Why it happens
- Plan-level request rate, a method-specific rule, concurrent connections, or an add-on allowance was exceeded.
- A JSON-RPC batch still counts each call inside the batch toward applicable limits.
How to identify it
- Read the response body to distinguish the limit and inspect usage around the same timestamp in the dashboard.
- Use Retry-After when the response supplies it.
How to resolve it
- Throttle requests, cap concurrency, and retry after the indicated delay with bounded backoff.
- Adjust an endpoint or method rate-limit rule, or change the plan/add-on allowance when sustained traffic requires it.
#
The server failed while processing the request.
Diagnose and resolve
Why it happens
- An unexpected failure occurred in the gateway, node client, or upstream service.
How to identify it
- Check whether identical read requests fail repeatedly and capture the timestamp, method, network, and response from Endpoint Logs.
How to resolve it
- Retry idempotent read requests with bounded backoff. Do not blindly resubmit a transaction without first checking whether it was accepted.
- If the error persists, send the non-secret request details and timestamp to support.
#
The endpoint or an upstream service is temporarily unable to handle the request.
HTTP Error Code Example
The code snippet below is an example of Error Code 429.
{
"jsonrpc": "2.0",
"error": {
"code": 429,
"message": "The requests per second (RPS) of your requests are higher than your plan allows."
},
"id": 1
}Hemi RPC Error Codes
Let's look at the common Hemi RPC Error Codes you can encounter, what they mean and what you can do to prevent them.
RPC#
The JSON-RPC server could not parse the JSON text. JSON-RPC defines -32700 for this condition, although gateways or clients can return a different code with a parse-related message.
Diagnose and resolve
Why it happens
- Invalid JSON syntax or a truncated request body.
How to identify it
- The response id is normally null because the server could not reliably identify the request.
- Validate the exact serialized bytes sent over the network, not only the in-memory object.
How to resolve it
- Generate the payload with a JSON serializer and correct quoting, commas, brackets, and encoding.
RPC#
The JSON is valid, but it is not a valid JSON-RPC Request object.
Diagnose and resolve
Why it happens
- jsonrpc is missing or not "2.0", method is not a string, params is not an array or object, or the request object has an invalid shape.
How to identify it
- Unlike -32700, a JSON parser can read the payload; validation of the Request object fails afterward.
How to resolve it
- Build a Request object that follows JSON-RPC 2.0 and the documented method example.
RPC#
The requested method does not exist or is not available on this endpoint.
Diagnose and resolve
Why it happens
- A misspelled or case-mismatched method name, an API not supported on the selected network, or a method that requires an add-on.
How to identify it
- Inspect the exact method string. Method names are case-sensitive.
- Confirm that the endpoint network and enabled APIs support the method.
How to resolve it
- Use the method name exactly as documented and enable any API or add-on it requires.
RPC#
The method exists, but one or more parameters are missing, incorrectly ordered, incorrectly typed, or incorrectly encoded.
Diagnose and resolve
Why it happens
- Wrong parameter count or order, invalid address/hash encoding, an unsupported option, or a value outside the method contract.
How to identify it
- Read the error message for the argument index or validation detail and compare params with the method reference.
How to resolve it
- Correct the named argument and preserve required encodings such as 0x-prefixed Ethereum quantities and data.
RPC#
The JSON-RPC server encountered an internal error while handling the request.
Diagnose and resolve
Why it happens
- A node-client or upstream failure occurred after the request was accepted for processing.
How to identify it
- Record error.data when present and determine whether the same valid request fails repeatedly.
How to resolve it
- Retry an idempotent read once with bounded backoff. If it persists, provide the request method, network, timestamp, and Endpoint Log to support.
RPC#
EIP-1474 assigns -32000 to missing or invalid Ethereum RPC input. The -32000 to -32099 range is implementation-defined, so always use the message and data to classify the actual error.
Diagnose and resolve
Why it happens
- A required value is missing, malformed, or invalid for the client handling the request.
How to identify it
- Inspect error.message and error.data; the numeric code by itself is not enough to diagnose implementation-defined server errors.
How to resolve it
- Correct the specific input named by the client. Do not retry an unchanged invalid request.
RPC#
The requested block or other resource was not found.
Diagnose and resolve
Why it happens
- The identifier does not exist, is not canonical when canonical data was required, or is outside the node’s available history.
How to identify it
- Verify the block hash or number and compare it with the selected network and the endpoint’s available history.
How to resolve it
- Correct the identifier or use an endpoint with the required historical data.
RPC#
The requested resource exists conceptually but is not currently available from the server.
RPC#
The server rejected transaction creation.
Diagnose and resolve
Why it happens
- Transaction validation failed; the exact reason is client-specific and should be present in the message or data.
How to identify it
- Inspect the full message and data before deciding whether the transaction needs a new nonce, fee, balance, gas limit, or signature.
How to resolve it
- Fix the stated transaction problem and rebuild or re-sign when any signed field changes. Do not blindly resubmit the same payload.
RPC#
The requested method is not implemented or supported by the server.
Diagnose and resolve
Why it happens
- The node client or endpoint configuration does not implement the method.
How to identify it
- Confirm the method against the endpoint network, supported API, and client-specific namespace.
How to resolve it
- Use a supported method or an endpoint/API that implements the required namespace.
RPC#
The request exceeds a server-defined limit.
Diagnose and resolve
Why it happens
- The query range, result size, batch, timeout, or another client-defined bound is too large.
How to identify it
- Use the message and data to identify the specific limit.
How to resolve it
- Reduce the query range or batch size, paginate where supported, and avoid repeating an unchanged oversized request.
RPC#
The specified JSON-RPC version is not supported by the server.
Diagnose and resolve
Why it happens
- The jsonrpc member specifies an unsupported protocol version.
How to identify it
- Inspect the top-level jsonrpc member in the exact serialized request.
How to resolve it
- Set jsonrpc to the string "2.0".
Quicknode#
The endpoint exceeded its configured or plan-level per-second request allowance.
Diagnose and resolve
Why it happens
- The aggregate request rate crossed the per-second limit.
How to identify it
- Confirm Quicknode RPC code -32007 and correlate the timestamp with request-rate metrics.
How to resolve it
- Throttle the caller, cap concurrency, and spread burst traffic over time.
- Increase the applicable limit or plan capacity when the sustained request rate requires it.
Quicknode#
The endpoint exceeded its configured or plan-level per-minute request allowance.
Diagnose and resolve
Why it happens
- The aggregate request count crossed the rolling per-minute limit.
How to identify it
- Confirm Quicknode RPC code -32008 and compare the timestamp with request metrics over a full minute.
How to resolve it
- Queue or throttle requests so bursts remain below the per-minute allowance.
- Increase the applicable limit or plan capacity when the sustained request volume requires it.
Quicknode#
A method-specific rate-limit rule rejected the request.
Diagnose and resolve
Why it happens
- Calls to the named RPC method exceeded its configured limit.
How to identify it
- Confirm Quicknode RPC code -32011, then use Endpoint Logs to identify the method and matching rate-limit rule.
How to resolve it
- Reduce or cache calls to that method, or update the method rule if the traffic is expected.
Quicknode#
The request is missing required JSON-RPC envelope fields or has an invalid structure.
Diagnose and resolve
Why it happens
- The JSON-RPC envelope is incomplete—missing jsonrpc, method, or id fields.
- The request was routed to an internal parser that expects a different format.
- The method field is empty or missing.
How to identify it
- Confirm source Quicknode and code -32604; do not confuse it with standard JSON-RPC -32601 (method not found).
- Check if the error message mentions missing fields like jsonrpc, id, or type.
How to resolve it
- Include the complete JSON-RPC 2.0 envelope: jsonrpc, method, params, and id fields.
- Ensure jsonrpc is set to "2.0", method is a non-empty string, and id is present.
Quicknode#
The request was rejected by an endpoint security filter, such as a method allowlist or blocklist. Review the endpoint's request filter settings.
Diagnose and resolve
Why it happens
- A method or request filter configured on the endpoint denied the request.
How to identify it
- Confirm source Quicknode and code -32611, then match the method and caller with the endpoint security rules.
How to resolve it
- Allow the request only if it is intended; otherwise keep the filter in place and correct the caller.
Quicknode#
The request exceeded a rate limit. This code may appear for method-specific or connection-based limits.
Diagnose and resolve
Why it happens
- The request rate for a specific method or connection exceeded the configured limit.
How to identify it
- Confirm source Quicknode and code -32029. Check the error message for retry timing.
How to resolve it
- Wait for the indicated retry period before sending another request.
- Reduce request frequency or implement exponential backoff.
Hemi RPC Error Code Example
The code snippet below is an example of Error Code -32601.
{
"jsonrpc": "2.0",
"id": 1,
"error": {
"code": -32601,
"message": "the method eth_randomMethod does not exist/is not available"
}
}JSON-RPC reserves codes -32000 through -32099 for implementation-defined server errors. EVM chains can run different node clients, so the same code can carry different meanings. Diagnose these responses using the code, message, and data together; do not base retry behavior on the numeric code alone. See the JSON-RPC 2.0 error definition and the EIP-1474 Ethereum error table.
Endpoint Logs
Quicknode provides logs for your RPC endpoints to help you diagnose issues. You can view logs directly in your Quicknode dashboard by navigating to:
- Endpoints in the sidebar
- Selecting your endpoint
- Opening the Logs tab
You can filter logs by time window, response type, method, and network.
What Gets Logged
Endpoint Requests
Requests made to your endpoint, including the HTTP status, request method, RPC method or path, and timestamp.
Error Details
When available, failed requests include error details such as RPC error codes, request and response bodies, and links to related documentation.
Logging Limitations
Log availability can vary by method, response type, network, and plan. To maintain optimal endpoint performance, logging operates on a best-effort basis. Some logs may be dropped during high-traffic periods to preserve low latency.
Diagnose an Error From Its Log
Use the matching log entry to compare the request and response before changing your integration.
- Filter to the smallest time window, method, and network that contain the failed request.
- Check the HTTP status first. If the response body contains a JSON-RPC error object, record its code, message, and data separately.
- Compare the logged request method and parameters with the method reference. For implementation-defined RPC codes, the message and data are required to identify the cause.
- Keep the timestamp and request ID when escalating an issue, but redact endpoint tokens, authorization headers, private keys, and signed payloads that should not be shared.
Retention and Access
Build and Scale plans include dashboard access with standard log retention. Enterprise plans provide extended retention periods and programmatic log retrieval through the Admin API.
For service availability or active incidents, check the Quicknode Status Page.
If you're experiencing other error codes, please let us know by submitting a ticket. We're more than happy to assist