Integration overview

How applications coordinate wallet authority, platform workflows, and on-chain state.

Three kinds of interaction

Your application works with three things: the platform API, indexed chain data, and wallet-signed transactions. Each has a different job. If you treat all three as one synchronous operation, your status displays can mislead users.

Layer	Responsibility
Platform services	Sessions, organization access, verification workflows, claims orchestration, and durable jobs
Indexer and read services	Searchable projections of balances, transfers, identities, claims, and asset records
Contracts and wallets	Enforce on-chain permissions and rules, authorize transactions, and record execution

Authentication and authority

The portals use Sign-In with Ethereum to open sessions linked to a wallet. Workspace membership controls platform actions, and contract roles control on-chain actions (details). Existing Safe accounts add scoped owner or delegate access.

Your application should show which account and wallet are acting. It should also show whether a step prepares an operation or authorizes it.

Transaction and job state

Some platform operations create durable jobs, such as issuer registration, claims issuance, or suite deployment. Others ask an issuer or investor wallet to sign directly.

Show each stage clearly: requested, awaiting authorization, submitted, confirmed, and indexed. How transactions settle explains what each stage proves, how to handle indexer delay, and why you must not create duplicate requests.

Read models and preliminary checks

The platform normally reads chain-derived data through its indexer. This makes queries efficient, but it adds a delay between execution and display. Your integration should tell users how fresh the data is and which updates are pending.

Transfer preflight (a trial check before signing) uses current information to explain likely refusals. When the transaction executes, the contracts decide the result.

Environment boundaries

Get the network and contract configuration for the environment you target. Token addresses, available market features, onboarding policy, and payment assets differ between deployments. Testnet self-service access does not give production admission or Business Validator permission.

Discover testnet configuration

The portal platform exposes public configuration at:

GET https://testnet.rwa-platform.real.finance/v1/config

Relevant fields from a Real Testnet response:

{
  "network": "testnet",
  "chainId": 117711,
  "features": {
    "escrowDvpEnabled": true,
    "secondaryMarketEnabled": true,
    "issuerOnboardingEnabled": true,
    "automaticTokenDeployment": true,
    "testnetVerification": true,
    "marketplacePublishing": true
  },
  "navStalenessDays": 1
}

This is an excerpt. The response also includes rpcUrl, explorerUrl, contract addresses, and claim topics.

testnetVerification: Get verified runs a test verification instead of real KYC.
marketplacePublishing: a workspace Admin can publish their own asset in the Marketplace.

Feature flags describe the service that responds. They do not prove that every asset supports a feature. They do not prove that a production audit gate has been met.

Read and authenticate at the right service

Request	Access	Result
`GET /v1/config`	Public	Deployment configuration and feature flags
`GET /v1/assets?limit=1`	Public, rate-limited	Listed assets in `data`, with `pagination` and freshness `meta`
`GET /v1/assets/:token`	Public, rate-limited	One listed asset and its documents
`GET /v1/portfolio`	Wallet session	Account-scoped positions and freshness information
`POST /v1/transfers/preflight`	Wallet session and CSRF protection	Preliminary transfer checks; no transfer submission

These routes belong to testnet.rwa-platform.real.finance. Do not mix them up with the network/protocol API at testnet.api.real.finance/v1 or with separate indexer APIs. An API key does not open a portal wallet session. The portal authentication flow uses Sign-In with Ethereum, scoped sessions, and CSRF protection for mutations.

Handle HTTP failures before you parse success data. Protected routes can reject missing sessions or insufficient permissions. Rate limits can return 429. An unlisted or unknown asset can return 404. Keep the returned application error codes, such as nav_stale. Do not treat every 409 as a reason to repeat an action.

For a complete viem read and contract simulation, use Build an application. That contract simulation is different from the account-scoped platform preflight above.

Testnet services

The tokenization API provides the platform entry point. Check API readiness and indexer health separately. The network endpoint directory also lists chain and protocol services.

Integration overview

On this page