How do you access Sui data with RPC and data providers?

Sui is a high-throughput network where application state lives in objects rather than a single global account ledger. That design shapes how you read data: most queries are object-centric, and the RPC surface is built around objects, transactions, checkpoints, and events. If you are wiring a wallet, indexer, or dashboard to Sui, you need an endpoint that can answer those queries reliably under your real traffic.

This page is a practical reference for Sui RPC and data access. It explains what the RPC interface exposes, how to configure an endpoint, how to make real requests, and how to decide between public fullnodes, a managed RPC API, and a dedicated node.

Choosing your Sui data access path

Before you write integration code, decide which access path matches your workload. The three common paths differ mainly in isolation, capacity, and how much operational work you own.

A quick rule of thumb: if you are still exploring the API, a public fullnode is fine. Once you have real users, move to a managed RPC API so you are not competing for shared capacity. If your workload is large, bursty, or needs predictable behavior, look at a dedicated node so your traffic is not affected by other tenants.

OnFinality provides Sui RPC through its API service and dedicated node options, so you can start on a managed endpoint and move to dedicated infrastructure as load grows. You can review the network details on the Sui RPC page.

What the Sui RPC interface exposes

The Sui fullnode JSON-RPC API is organized around the network's core data types. The methods you will use most often fall into a few groups:

• Object reads: fetch an object by ID, including its type, owner, and version.
• Transaction reads: fetch a transaction by digest and inspect its effects and events.
• Checkpoint reads: retrieve checkpoint data and the transactions it contains.
• Event queries: query events by type, sender, or module, which is how most indexers track activity.
• Coin and balance reads: look up coin objects and balances for an address.
• Execution: submit a signed transaction for execution.

Because Sui state is object-based, you will often resolve an address to its owned objects, then read each object, rather than reading a single account balance. Plan your data model around that pattern early, because it affects how you cache and index.

Method names and parameters evolve with the network, so treat the official Sui documentation as the source of truth for the exact method list and request shapes. This page focuses on how to connect and operate against that interface.

Configuring a Sui endpoint

A Sui endpoint is an HTTP JSON-RPC URL. You point your client at it and send standard JSON-RPC requests. The same URL works for curl, JavaScript SDKs, and backend services.

Store the endpoint in an environment variable rather than hardcoding it, so you can switch between development and production without code changes:

# .env
export SUI_RPC_URL="https://your-onfinality-sui-endpoint"

Then reference it from your client. In JavaScript, the Sui SDK accepts a fullnode URL when you create a client:

import { SuiClient, getFullnodeUrl } from '@mysten/sui/client';

// Use your managed endpoint in production; the helper is convenient for local tests.
const client = new SuiClient({
  url: process.env.SUI_RPC_URL ?? getFullnodeUrl('mainnet'),
});

const object = await client.getObject({
  id: '0xYOUR_OBJECT_ID',
  options: { showType: true, showOwner: true },
});

console.log(object.data?.type, object.data?.owner);

For a raw check that your endpoint is reachable and returning data, send a JSON-RPC request directly:

curl -s "$SUI_RPC_URL" \
  -H 'content-type: application/json' \
  -d '{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "sui_getLatestCheckpointSequenceNumber",
    "params": []
  }'

A healthy response returns a JSON result with the latest checkpoint sequence number. If you get an error object instead, check the method name and parameters first, then the endpoint itself.

Reading Sui data: objects, transactions, and events

Most Sui integrations follow the same three-step pattern: resolve what you need, read it, then track changes.

1. Resolve. Given an address or a known ID, find the objects or transactions you care about. For an address, query owned objects. For a known digest, fetch the transaction directly.
2. Read. Fetch the object or transaction with the fields you need. Request only the options you use, since large responses cost bandwidth and time.
3. Track. Subscribe to or poll for events and checkpoints so your application state stays current.

Event queries are the backbone of most indexers. You filter by event type, module, or sender, then page through results. Because event volume on a busy network can be high, design your queries to page rather than request everything at once, and store a cursor so you can resume after a restart.

If you are building a backend that needs historical state, confirm that your provider offers archive access for the ranges you need. Not every endpoint keeps full history, and that gap is a common source of surprises late in a project.

Production readiness checklist

Use this checklist before you send real traffic to a Sui endpoint. It is written so you can hand it to whoever owns reliability for your app.

If you cannot answer several of these, a managed RPC API is usually the faster path than running your own fullnode. OnFinality's RPC pricing page outlines plan tiers, and the supported RPC networks list shows where Sui fits alongside other chains.

Common failure modes and how to debug them

Sui RPC issues usually fall into a few recognizable categories. Match the symptom to the likely cause before changing anything.

A useful debugging habit is to compare two endpoints side by side. Query the latest checkpoint sequence number from each and compare. If one is consistently behind, that endpoint is lagging, and you should route traffic away from it until it catches up.

For a broader look at endpoint selection and failover design, see how to choose an RPC provider.

When to move to a dedicated Sui node

Managed RPC handles most production workloads well. A dedicated node becomes worth considering when one or more of these apply:

• Your traffic is large enough that shared capacity creates unpredictable latency.
• You need isolation for compliance, security, or data-residency reasons.
• You run heavy event indexing or archive queries that would be expensive on a shared tier.
• You want control over node version and configuration without operating the hardware yourself.

A dedicated node is not automatically the right answer. It adds cost and planning, and it only pays off when your workload is steady enough to justify it. If you are unsure, start managed and measure. When latency or throttling becomes a recurring theme, that is your signal to evaluate dedicated infrastructure. OnFinality's dedicated node offering is the place to review that option.

Key Takeaways

• Sui data access is object-centric, so design your queries and caching around objects, transactions, checkpoints, and events.
• Public fullnodes are fine for learning; production apps should use a managed RPC API, and high-volume or isolated workloads should consider a dedicated node.
• Keep the endpoint in configuration, define a failover, and set timeouts and retries before launch.
• Event queries need filters and cursors; archive needs must be confirmed up front.
• Most Sui RPC problems are diagnosable by comparing checkpoint sequence numbers and checking method names against the current docs.

FAQ

Do I need a Sui fullnode to read data?

No. You can read Sui data through any reachable JSON-RPC endpoint, including a managed RPC API. Running your own fullnode is only necessary if you need full control over the node or specific isolation requirements.

What is the difference between a Sui RPC provider and a data provider?

An RPC provider gives you a live endpoint that answers JSON-RPC queries against the current chain state. A data provider may add indexing, historical queries, or aggregated datasets on top. Many teams use both: RPC for live reads and writes, and indexed data for analytics and history.

Why do my Sui event queries time out?

Broad event queries without filters or paging can return very large result sets. Add filters by type, module, or sender, and page through results using cursors so each request stays small.

How do I check whether a Sui endpoint is healthy?

Query the latest checkpoint sequence number from the endpoint and compare it with a second endpoint. A consistently lower number means the endpoint is lagging.

Can I use OnFinality for Sui RPC?

Yes. OnFinality offers Sui RPC through its API service and dedicated node options. See the Sui RPC page for network details and RPC pricing for plan information.