Skip to main content
There are a few ways to put Rheon inside your product. One is live today (the API); the embed methods are being built - their planned shape is shown inline below so you can see where each is headed.
The deposit API is available now - build your own UI on it (see the API reference). The widget runs as a live preview at widget.rheon.io.

​
Deposit API

Available now. The deposit API is three calls - quote, build the transaction, track status - on the same rails the widget runs on. It is non-custodial: the API returns unsigned transactions and the user’s wallet signs them. Use it when you want your own UI end to end. Calling it from your own backend? Start with Server-side integration for the key, the /v1 prefix and the whole flow in order.

​
Embeddable widget

Coming soon. The widget will drop into your page in a few lines. The design below is the intended shape - expand it to see how each piece will work. It is a plan, not a live spec, and details may change as it ships.
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.
Planned - shape may change
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.
The widget will be 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 → 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).
Embedded via the SDK (or postMessage from the iframe), the widget will emit events so your page reacts without polling. Planned set:
  • 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.