Integration options

Two ways to integrate: the SDK for a ready-made flow, the API for your own UI.

There are two ways to put Rheon inside your product, and the choice is only about who builds the interface.

	Rheon SDK	Rheon API
Who builds the UI	We do - you embed the finished flow	You do
What you write	An embed, plus a backend call to open a session	Your own screens against our endpoints
Best when	You want to ship fast and the flow suits you	You want your own design, or the flow has to fit an existing checkout

“Rheon API” and “server-side integration” are the same path, not two. The Rheon API page is both the catalogue - which products exist and what each one exposes - and the walkthrough of using it: the key, the /v1 prefix, and the calls in order.

Both run on the same rails and the same keys. Whichever you pick, anything your backend must trust - crediting a user, releasing an order - comes from a status you fetched or a webhook you verified, never from the browser.

Rheon API

Call the endpoints from your own backend and keep your UI. For crypto deposits that is three calls - quote, build the transaction, track status - and it is non-custodial throughout: we return unsigned transactions and the user’s wallet signs them.

Start with Rheon API for what each product exposes and the flow in order.

Rheon SDK

The flow runs at widget.rheon.io and embeds into your own page in the modes below. What the SDK covers per product is on Rheon SDK.

Embed modes - iframe, SDK, redirect

Three ways to embed, so you can trade off speed vs control:

• Hosted iframe - the full widget, either as an overlay on top of your page or embedded into a DOM element. Fastest to ship.
• Web SDK - the widget as a component, with lifecycle events and theming hooks, so your app reacts to the flow in real time.
• Redirect - send the user to a hosted Rheon URL and they return after, for cases where you cannot embed.

Hosted iframe

<iframe
  src="https://widget.rheon.io/?token=<SIGNED_SESSION_TOKEN>"
  allow="camera;microphone;payment"
  style="height:100%;width:100%;border:none">
</iframe>

Secure signed widget URL

For production white-label deposits, your backend requests a signed widget URL rather than building one from raw query params on the client. The signature means the amount, destination, and branding cannot be tampered with client-side. The token is single-use and short-lived.

This is the recommended pattern when the host app must not be able to alter the deposit configuration.

Configuration - filtering and pre-fill

The widget is configurable so it fits your product:

• Chain / token filtering - restrict which source chains and tokens the user sees (chains.allow / deny, tokens.allow / deny / featured). Rheon’s reach is “any asset, any chain to USDC”, so most partners will want to narrow it.
• Pre-fill - pass walletAddress, amount, target chain/token, email to skip screens. Each pre-filled field is one fewer step for the user.
• Lock fields - mark any pre-filled field as non-editable, so the user cannot change a value you fixed (e.g. the destination).

Lifecycle events (in-page UX)

Embedded via the SDK (or postMessage from the iframe), the widget emits events so your page reacts without polling:

• DepositStarted - the user confirmed, routing began
• Routing - settling cross-chain
• SourceConfirmed - source payment confirmed
• Completed - USDC landed
• Failed - the deposit failed

Use these for in-page UX only. Anything your backend must trust (crediting a user) goes through webhooks, never a client event.