Sui RPC Rate Limit: What Developers Should Check Before Scaling

Quick diagnosis: is your Sui app actually rate limited?

Before you change providers or rewrite your indexer, confirm that throttling is the real cause. Sui RPC rate limits usually show up as one of these signals:

• HTTP 429 Too Many Requests responses from the RPC endpoint.
• JSON-RPC error objects with a message about request limits, quota, or too many requests.
• Sudden latency spikes where requests still succeed but take much longer.
• Partial failures: some calls in a batch succeed, others are rejected.
• WebSocket or subscription disconnects under load.

If you see these only during deploys, backfills, or traffic peaks, you are almost certainly hitting a request cap rather than a node fault. If they happen constantly at low volume, check your API key, endpoint URL, and whether you are accidentally sending duplicate requests.

A quick way to confirm is to log the HTTP status and JSON-RPC error body for every call, then count failures per minute. The table below maps common symptoms to likely causes.

Once you know which pattern you are seeing, the next step is to decide whether to reduce load, change how you call Sui, or move to infrastructure with capacity that matches your workload.

How Sui RPC limits are usually structured

Sui exposes a JSON-RPC interface, and most providers apply limits at more than one layer. Understanding these layers helps you predict where you will hit a wall.

Per-key request rate. The most common limit is requests per second (RPS) or requests per minute (RPM) tied to an API key. Public endpoints often apply this per IP address instead, which means a shared NAT or CI runner can consume the budget for everyone behind it.

Compute-weighted limits. Not all Sui methods cost the same. A simple sui_getLatestCheckpointSequenceNumber is cheap. Methods that return large object sets, transaction history, or event streams consume more node resources and may be weighted more heavily or capped separately.

Payload and response size caps. Large sui_getEvents or object queries can be limited by response size or result count, independent of request rate.

Connection and subscription limits. WebSocket connections, active subscriptions, and concurrent streams are often limited separately from HTTP request rates.

Burst versus sustained limits. Many providers allow short bursts above the steady-state rate, then throttle if you sustain that level. This matters for indexers that catch up quickly and then idle.

Because these limits vary by provider and plan, the practical approach is to measure your own traffic profile and compare it against the limits documented for your endpoint. If your provider does not document method-level or subscription limits clearly, treat that as a risk when you plan capacity.

Measure your real Sui request profile first

You cannot choose the right fix without knowing what you actually send. Instrument your client to record, per method:

• Calls per second at peak and at average.
• p50, p95, and p99 latency.
• Error rate by status code and JSON-RPC error code.
• Retry count and how retries amplify load.
• Number of concurrent WebSocket subscriptions.

A small monitoring probe can make this visible. For example, a Node.js script that samples a lightweight Sui method and records status and latency:

// monitor-sui.js
const ENDPOINT = process.env.SUI_RPC_URL; // your Sui RPC endpoint

async function probe() {
  const started = Date.now();
  const res = await fetch(ENDPOINT, {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify({
      jsonrpc: "2.0",
      id: 1,
      method: "sui_getLatestCheckpointSequenceNumber",
      params: []
    })
  });
  const body = await res.json();
  console.log({
    status: res.status,
    ms: Date.now() - started,
    error: body.error ? body.error.message : null
  });
}

setInterval(probe, 1000);

Run this from the same region as your production workload. If you see 429 responses at a rate you did not expect, your effective limit is lower than your plan suggests, or something else is sharing your key.

For a direct JSON-RPC check from the command line:

curl -s -o /dev/null -w "%{http_code} %{time_total}s\n" \
  -X POST "$SUI_RPC_URL" \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"sui_getLatestCheckpointSequenceNumber","params":[]}'

If you need a working endpoint to test against, start from the Sui RPC network page and use the endpoint listed there for your environment.

Reduce load before you change providers

Sometimes the cheapest fix is to send fewer, smarter requests. These patterns reduce Sui RPC pressure without changing infrastructure:

• Batch where the API supports it. JSON-RPC batch requests let you combine multiple calls into one HTTP round trip, which can reduce per-request overhead and help you stay under request-rate caps.
• Cache immutable data. Checkpoints, finalized transactions, and historical objects do not change. Cache them locally or in Redis instead of re-fetching.
• Use subscriptions instead of polling. If you are polling for new checkpoints or events every second, a subscription or a well-tuned polling interval can cut request volume dramatically.
• Add jittered backoff. Retries without backoff turn a brief throttle into a sustained overload. Use exponential backoff with jitter and a retry budget.
• Separate read paths. Route heavy analytics or backfill jobs to a different endpoint or key than your user-facing app so one workload cannot starve the other.
• Trim result sets. Request only the fields you need and paginate large queries instead of pulling everything at once.

These changes often buy enough headroom for early-stage apps. They also make your traffic profile clearer, which helps when you evaluate dedicated capacity later.

When a shared Sui endpoint stops being the right fit

Shared and public endpoints are a reasonable starting point. They become a constraint when your workload has any of these characteristics:

• Sustained request rates that approach or exceed your plan's cap.
• Heavy use of event queries, object queries, or historical data.
• Many concurrent WebSocket subscriptions.
• Strict latency requirements for user-facing transactions.
• Multiple teams or services sharing one API key.
• Backfills and indexers that compete with production traffic.

At that point, the decision is less about finding a bigger shared plan and more about whether you need capacity that is not shared with other customers. Dedicated Sui node infrastructure gives you a node (or set of nodes) provisioned for your workload, so your throughput is not affected by other tenants' traffic. OnFinality offers both RPC API access and dedicated node options, so you can start shared and move to dedicated capacity as your request profile grows.

Options compared: shared RPC, higher-tier RPC, dedicated nodes

OnFinality's RPC API service is designed so teams can start on shared endpoints and move to dedicated nodes without changing their integration pattern. For current plan details, see RPC pricing.

Production readiness checklist for Sui RPC

Use this checklist before you scale a Sui workload:

1. Know your peak RPS per method. Not just total requests, but which methods dominate.
2. Confirm your plan's limits in writing. Request rate, method weights, payload caps, and subscription limits.
3. Implement backoff and retry budgets. Never retry in a tight loop.
4. Add a fallback endpoint. A second provider or a dedicated node reduces single-point failure risk.
5. Monitor error codes continuously. Alert on 429 rate, not just on total errors.
6. Separate workloads. Give indexers and user-facing traffic different keys or endpoints.
7. Test failover. Simulate your primary endpoint failing and confirm your app degrades gracefully.
8. Plan for growth. Estimate request volume at 2x and 5x your current traffic and check whether your plan still fits.

If several of these items are unclear for your current provider, that is a signal to evaluate alternatives. The RPC provider selection guide walks through the criteria in more detail.

Common mistakes that look like rate limits

Not every failure is throttling. These issues produce similar symptoms:

• Wrong network or endpoint. Pointing a Sui client at a testnet endpoint, or vice versa, produces errors that can look like rejections.
• Malformed JSON-RPC payloads. A missing params array or wrong method name returns an error, not a rate limit.
• Expired or rotated API keys. An invalid key may be rejected in a way that resembles throttling.
• Clock or nonce issues in signed transactions. Transaction submission failures are often unrelated to request rate.
• DNS or TLS problems. Intermittent connection errors can mimic throttling under load.

Check the JSON-RPC error code and message before assuming a rate limit. 429 and explicit quota messages point to throttling; method-not-found or invalid-params errors point to client bugs.

Key Takeaways

• Sui RPC rate limits are usually applied per API key or IP, and often include method-level or compute-weighted caps.
• 429 responses, latency spikes, and subscription drops are the main signals of throttling.
• Measure your request profile per method before changing providers; retries can amplify load significantly.
• Batching, caching, subscriptions, and backoff often resolve early-stage throttling.
• When sustained throughput, heavy event queries, or many subscriptions exceed shared limits, dedicated Sui node infrastructure is the more predictable option.
• OnFinality provides Sui RPC API access and dedicated nodes; check supported RPC networks and RPC pricing for current details.

Frequently Asked Questions

Does Sui have a built-in RPC rate limit? Sui itself is a network; rate limits are applied by the RPC providers and node operators that expose endpoints. Public endpoints typically apply per-IP limits, while managed providers apply per-key limits that vary by plan.

What does a Sui rate limit error look like? Most commonly an HTTP 429 Too Many Requests status, sometimes with a JSON-RPC error body describing a quota or request limit. Some providers return a generic error message, so log the full response.

Can I avoid rate limits by using multiple API keys? Sometimes, but check your provider's terms. Many providers aggregate limits per account, and spreading requests across keys can violate usage policies. The cleaner path is to reduce load or move to capacity that matches your workload.

When should I move to a dedicated Sui node? When your sustained request rate approaches your plan's cap, when heavy event or historical queries dominate, when you run many concurrent subscriptions, or when latency-sensitive traffic shares an endpoint with batch jobs.

Does OnFinality offer Sui RPC? Yes. OnFinality provides Sui RPC API access and dedicated node options. See the Sui network page for endpoint details and RPC pricing for plan information.

How do I test whether my app is being throttled? Run a lightweight probe against your endpoint from your production region, log status codes and latency, and compare the failure pattern against your request rate. If failures cluster at peak traffic, throttling is the likely cause.