Sui RPC Guide: JSON-RPC Migration for Developers

Sui RPC changes can break production apps in quiet ways. A wallet may still connect, but transaction polling starts timing out. An indexer may keep ingesting data, but object reads return shapes your parser did not expect. A backend may pass health checks while one critical method now behaves differently. For teams shipping on Sui, the migration problem is less about theory and more about protecting real user flows.

This guide focuses on practical Sui RPC migration work: how to audit your current usage, map dependencies, choose the right transport, and roll out changes safely. If you are moving from a hardcoded endpoint, replacing legacy assumptions, or standardizing access across services, you need a plan that covers compatibility, observability, and fallback behavior.

We will also show how to connect through Nadcab RPC using the Sui endpoint format https://rpc.nadcab.com/sui/<your-api-key>. The goal is not just to switch URLs, but to make your wallet, backend, and indexing stack more resilient during the transition.

Why Sui RPC changes matter for production apps

RPC migrations rarely fail all at once. More often, they fail at the edges: a method becomes unavailable, response timing changes, a subscription path behaves differently, or a pagination assumption stops working. On Sui, those issues can affect any service that depends on object state, transaction execution, event reads, or account activity.

Production teams usually discover this in three places first:

• Wallet flows: balance reads, owned object queries, and transaction signing pipelines.
• Backend services: payment confirmation, state sync jobs, and user activity feeds.
• Indexers and analytics: event collection, checkpoint processing, and data backfills.

If you run multiple environments, the risk grows. Staging may use one endpoint, production another, and internal tools a third. That creates configuration drift and inconsistent method support. A managed gateway can reduce that operational sprawl by standardizing how services access Sui and other networks. For example, Nadcab RPC supports Sui alongside many other chains behind one API key and consistent endpoint structure.

The main lesson is simple: treat Sui RPC migration as an application change, not just an infrastructure change.

How Sui’s RPC model differs from EVM-style endpoints

Teams coming from Ethereum-style JSON-RPC often assume Sui will fit the same patterns. It does not. Sui uses a different data model and different method families, so migration work often fails when code is written around EVM assumptions.

Different state model

EVM apps usually think in terms of accounts, storage slots, logs, and receipts. Sui apps often work with objects, ownership, versions, and checkpoint-based progression. That changes what your app asks the RPC for and how it stores responses internally.

Different method expectations

An EVM backend may rely on methods like eth_getLogs, eth_call, or eth_getTransactionReceipt. A Sui integration typically uses Sui-specific JSON-RPC methods for reading objects, transactions, events, and checkpoints. That means:

• You cannot assume method names or response shapes are interchangeable.
• You need to review serialization and parsing logic carefully.
• You should isolate chain-specific access behind adapters in your codebase.

Pagination and history patterns are different

Many teams discover that their retry logic or cursor handling is too generic. On Sui, history traversal and event retrieval may depend on cursors or checkpoints in ways that differ from EVM log polling. Build your ingestion jobs so they can resume from a known checkpoint or cursor, not from a block number abstraction copied from another chain.

If your team needs a refresher on how RPC layers fit into app architecture, Nadcab’s article on Web3 infrastructure explained: nodes, RPCs, and APIs is a useful background read before you redesign your access layer.

Audit your current Sui RPC usage before migrating

Before changing endpoints, list everything that touches Sui RPC today. Most teams underestimate this step and only discover hidden dependencies after rollout.

Build a method inventory

Search your codebase for:

• Direct JSON-RPC method strings
• SDK wrappers that call Sui under the hood
• Background jobs and cron workers
• Webhook processors that verify chain state
• Admin dashboards and internal scripts

Create a spreadsheet or config manifest with four columns: component, method, transport, and failure impact. That lets you see which endpoints are business-critical and which ones can tolerate fallback or delay.

Trace runtime dependencies

Not every dependency is obvious from source code. Your frontend may use one client library, while your worker queue uses another. Add request logging in non-production environments so you can observe real method usage and request volume patterns.

Classify by workload

Group RPC usage into categories:

• Read-heavy: balances, object fetches, activity screens
• Write-heavy: transaction submission, simulation, confirmations
• Streaming: subscriptions, event listeners, near-real-time monitors
• Historical: analytics jobs, backfills, reconciliation

This classification helps you choose between plain HTTPS polling, WebSocket subscriptions, and more specialized internal caching.

Review error handling now, not later

Check whether your app distinguishes between:

• Transport errors
• Method not found or unsupported method errors
• Timeouts
• Malformed responses
• Temporary upstream degradation

If all failures collapse into a single retry loop, migration will be harder to debug. Nadcab also has a practical piece on Web3 API integration, authentication, error handling, and RPC setup that maps well to this stage.

https://rpc.nadcab.com/sui/<your-api-key>

Choosing between HTTP, WebSocket, and provider-managed access

Sui apps often need more than one access pattern. The right setup depends on component behavior, not just preference.

When HTTP is enough

Use HTTPS for stateless reads, transaction submission, health checks, and backend workflows where polling is acceptable. HTTP is simpler to cache, easier to trace, and often easier to control in autoscaled environments.

When WebSocket helps

Use WebSocket where lower-latency updates matter, such as wallets waiting on transaction state changes or dashboards that display near-real-time activity. But do not assume WebSocket should replace all polling. Long-lived connections increase operational complexity, especially when clients reconnect frequently.

Why managed access can simplify migration

During a migration, one stable access layer is often more valuable than hand-managing multiple node URLs. Nadcab Cloud gives shared auto-scaling endpoints, while Nadcab Core is built for teams that want their own nodes with Nadcab’s routing engine in front. For more specialized needs such as dedicated clusters, custom auth, compliance logging, or enterprise SLA requirements, Nadcab Craft is the relevant option.

Update patterns for common app components: wallets, backends, indexers

Wallets

Wallet integrations should avoid embedding endpoint assumptions directly into UI code. Put the RPC URL in environment-specific configuration and centralize the client constructor. Also verify that wallet-side code handles partial outages gracefully. For example, if a balance query fails, the send flow should not always hard fail if transaction submission is still available.

Good wallet migration pattern:

• Centralize endpoint config
• Separate read client from submit client if needed
• Add explicit timeout handling
• Surface user-safe errors instead of raw RPC messages

Backends

Backends should treat Sui RPC calls as external dependencies with observability. Add request IDs, structured logs, retry caps, and metrics per method. If your backend performs confirmation checks, make sure it does not assume finality rules copied from EVM systems.

If you also operate on other chains, use a shared transport abstraction but keep chain-specific data mappers. That balance prevents code duplication without forcing one chain model onto another.

Indexers and data pipelines

Indexers should be resumable by design. Store the last successful checkpoint or cursor after every committed batch. Keep ingestion idempotent so a replay does not duplicate records. When migrating endpoints, run old and new pipelines in parallel for a validation window and compare output counts, timestamps, and selected sample records.

Teams doing archive-heavy work on other networks can review Nadcab’s guide on archive node vs full node for a broader framework on when historical access changes infrastructure choices.

Reliability checklist: failover, latency, and method compatibility

A safe migration needs a checklist you can hand to engineering and operations together.

If you want a managed gateway with smart routing across providers and regions, a live status page, and a 99.99% gateway uptime target, Nadcab RPC can simplify the failover side of this checklist. It does not remove the need for app-level compatibility tests, but it can reduce the burden of managing endpoint availability yourself.

How to connect to a Sui endpoint with a managed RPC gateway

The Nadcab RPC endpoint format is consistent across networks:

https://rpc.nadcab.com/<network-slug>/<your-api-key>

For Sui, use:

https://rpc.nadcab.com/sui/<your-api-key>

You can get an API key from the Nadcab RPC login page and review implementation details in the developer docs.

Raw JSON-RPC request with cURL

curl -X POST "https://rpc.nadcab.com/sui/<your-api-key>" 
  -H "Content-Type: application/json" 
  -d '{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "rpc.discover",
    "params": []
  }'

The exact methods you use will depend on your app and client library, but this basic pattern is enough to validate network reachability, auth configuration, and response handling.

JavaScript fetch example

const endpoint = "https://rpc.nadcab.com/sui/<your-api-key>";

async function callSui(method, params = []) {
  const res = await fetch(endpoint, {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify({
      jsonrpc: "2.0",
      id: Date.now(),
      method,
      params
    })
  });

  if (!res.ok) {
    throw new Error(`HTTP ${res.status}`);
  }

  const data = await res.json();
  if (data.error) {
    throw new Error(`${data.error.code}: ${data.error.message}`);
  }

  return data.result;
}

callSui("rpc.discover")
  .then(console.log)
  .catch(console.error);

If you support several chains from one backend, this endpoint pattern makes configuration easier. Sui can live next to Ethereum, Solana, and other supported networks under one account, which is helpful when building shared infrastructure across products.

For commercial planning, Nadcab RPC uses pay-as-you-go pricing at $0.375 per 1M compute units, and Nadcab Cloud starts from $10 with no rate tiers. That pricing model is useful when you want usage-based cost control instead of fixed request buckets.

Testing and rollout plan for a safe Sui RPC migration

Stage 1: replay critical reads

Start by replaying production-like read traffic in staging against the new endpoint. Compare returned fields, nullability, cursor behavior, and latency distribution for the methods that matter most to your app.

Stage 2: dual-run write-adjacent workflows

For workflows near transaction submission and confirmation, run the old and new paths side by side where possible. You may not submit twice, but you can often compare pre-submit checks, simulation reads, and post-submit confirmation polling.

Stage 3: parallel indexer verification

Run the new ingestion pipeline in shadow mode. Compare:

• Total events or transactions processed over the same window
• Checkpoint continuity
• Sampled records for exact field matches
• Recovery behavior after forced restarts

Stage 4: canary rollout

Move a small percentage of traffic first. Route one internal service, one region, or one non-critical user segment through the new Sui RPC endpoint. Watch error rate, timeout rate, reconnect behavior, and downstream queue growth.

Stage 5: full cutover with rollback window

Do not remove the old configuration immediately. Keep a rollback path for a defined window and document the switch criteria in advance. Rollback decisions should be based on user-facing outcomes, not just whether the endpoint answers requests.

This rollout style mirrors broader node infrastructure practice. For more architectural context, see Nadcab’s article on node infrastructure for dApps and RPC providers.

Final Thoughts

Sui RPC migration is an engineering reliability project, not a simple URL replacement. The teams that do it well start with a method audit, isolate chain-specific logic, test transport choices per workload, and roll out with clear fallback paths. Wallets, backends, and indexers each fail differently, so they should not share one generic migration checklist.

If you want to standardize access while reducing endpoint management overhead, Nadcab RPC gives you a consistent Sui endpoint at https://rpc.nadcab.com/sui/<your-api-key>, plus HTTPS and WebSocket access, one API key across supported networks, and a live operational status page. The important part is still your application design: validate methods, monitor behavior, and cut over in stages.

Done right, a Sui RPC migration becomes a chance to harden your whole stack: cleaner adapters, better observability, safer retries, and fewer hidden dependencies. That is the upgrade that matters most in production.