Skip to content
RVO Documentation

Errors & Retries

RVO returns explicit and deterministic error responses.

Errors are never silent, implicit, or heuristic-based. Every rejected request includes a clear reason so applications can respond correctly without guesswork.

Error categories

Section titled “Error categories”

Errors returned by RVO fall into three broad categories:

  • Authentication errors
  • Limit and quota errors
  • Platform and upstream errors

Each category has different retry semantics.

Authentication errors

Section titled “Authentication errors”

Authentication errors occur when a request cannot be associated with a valid API key.

Common causes include:

  • Missing API key header
  • Invalid or malformed API key
  • Revoked API key
  • API key not associated with an active plan

Authentication errors are not retryable.

If you receive an authentication error:

  • Verify the X-API-KEY header
  • Confirm the key is active in the dashboard
  • Ensure the request is sent to the correct endpoint

Retrying the same request without fixing the cause will always fail.

Limit and quota errors

Section titled “Limit and quota errors”

Limit-related errors occur when a request exceeds the allowed boundaries for the API key.

This includes:

  • Sustained traffic above the allowed rate
  • Exceeding the configured usage quota

When a limit is reached:

  • The request is rejected immediately
  • No server-side retry is performed
  • The error response indicates the limit condition

Limit errors may be retryable, depending on your traffic pattern.

Applications should:

  • Apply exponential backoff
  • Avoid immediate retries
  • Reduce request concurrency if limits are reached frequently

Persistent limit errors indicate that the workload has outgrown the current plan.

Platform and upstream errors

Section titled “Platform and upstream errors”

Platform errors represent temporary failures within the RPC infrastructure or upstream dependencies.

Examples include:

  • Transient network failures
  • Temporary RPC node unavailability
  • Internal processing errors

These errors are typically retryable.

Retries should:

  • Use exponential backoff
  • Include jitter to avoid retry storms
  • Respect existing rate limits

RVO does not automatically retry failed requests on behalf of clients.

Retry responsibility

Section titled “Retry responsibility”

Retry behavior is always the responsibility of the client.

RVO does not:

  • Queue failed requests
  • Retry requests automatically
  • Mask transient failures

This ensures request behavior remains explicit and observable.

Clients should implement retry logic that:

  • Differentiates between retryable and non-retryable errors
  • Applies backoff and jitter
  • Avoids retry loops during sustained failures

Monitoring error behavior

Section titled “Monitoring error behavior”

Error rates and rejected requests are visible in real time through the dashboard.

You can inspect:

  • Error classifications
  • Rejected request counts
  • Method-level error patterns

This allows you to distinguish between:

  • Application-level issues
  • Limit-related constraints
  • Platform-wide incidents

Live error visibility is available here:

👉 https://dashboard.rvo.network/usage

What’s next

Section titled “What’s next”

To understand how errors relate to platform reliability and communication, continue with:

  • Reliability & Status – monitoring, incidents, and service health
  • Production Setup – designing resilient client behavior