SiaSia Developer Portal

Connect a Storage Account

Before your app can store or retrieve anything, it connects to the user's storage account. In Sia terms, this means connecting to an indexer — the service that verifies your app's identity and tracks the user's stored data.

The flow is short: your app requests a connection, the user approves it once, and the SDK derives an App Key — the credential your app stores and uses for every session after that.

Prerequisites

  • An indexer URL — The SDK can connect to any Sia indexer, whether your own or a third-party. We recommend https://sia.storage, a hosted indexer that requires no setup and includes a 50GB free tier to get started.
  • A unique 32-byte App ID — Generate once per app and hardcode it. Changing it changes your users' derived keys and loses access to their data.
  • The Sia Storage SDK — See Install the SDK.

⚠️ Warning

The user's BIP-39 recovery phrase is their master key.

  • The recovery phrase must never be stored by your application, but instead stored securely by the user.
  • It should be used only once during onboarding to derive the App Key.
  • Your application should export and store the App Key securely for future sessions.

Example

rust
use sia_storage::{app_id, generate_recovery_phrase, AppKey, AppMetadata, Builder}; use std::io::{self, Write}; const INDEXER_URL: &str = "https://sia.storage"; const APP_META: AppMetadata = AppMetadata { // Replace `app_id` with your real 32-byte App ID (hex-encoded, 64 chars). // Generate this ONCE and keep it stable forever for your app. id: app_id!("0000000000000000000000000000000000000000000000000000000000000000"), name: "My App", description: "Demo application", service_url: "https://example.com", logo_url: None, callback_url: None, }; #[tokio::main(flavor = "multi_thread")] async fn main() -> Result<(), Box<dyn std::error::Error>> { // Create a builder to manage the connection flow let builder = Builder::new(INDEXER_URL, APP_META)?; // Request app connection and get the approval URL let builder = builder.request_connection().await?; println!("Open this URL to approve the app: {}", builder.response_url()); // Wait for the user to approve the request let builder = builder.wait_for_approval().await?; // Ask the user for their recovery phrase print!("Enter your recovery phrase (type `seed` to generate a new one): "); io::stdout().flush()?; let mut recovery_phrase = String::new(); io::stdin().read_line(&mut recovery_phrase)?; let mut recovery_phrase = recovery_phrase.trim().to_string(); if recovery_phrase == "seed" { recovery_phrase = generate_recovery_phrase(); println!("\nRecovery phrase:\n{recovery_phrase}\n"); } // Register an SDK instance with your recovery phrase let sdk = builder.register(&recovery_phrase).await?; // Export the App Key and store it securely for future launches let app_key = sdk.app_key().export(); println!("\nApp Connected!"); println!("App Key (hex): {}", hex::encode(app_key)); Ok(()) }

Understand what happened

What each step of the flow did:

Your app's identity

Your app is identified by its App ID and the metadata you supplied during request_connection, which is displayed to the user during approval:

  • id — A 32-byte App ID (Generated once and persists forever)
  • name — Name of your application
  • description — Explains the purpose of your app
  • service_url — The URL representing your app
  • logo_url (optional) — An icon shown to the user
  • callback_url (optional) — Used if your approval flow involves redirects

See Apps for the full identity model.

Why approval is required

The indexer enforces a one-time authorization step, so the user must explicitly grant your app access to their account.

After approval, the SDK can connect without user interaction using the stored app key.

The recovery phrase and the App Key

The App Key is deterministically derived from two inputs: the user's BIP-39 recovery phrase and your app's 32-byte App ID. It is a public/private key pair — the public key is registered with the indexer during onboarding, and the private key is what your app stores securely and signs requests with from then on.

Because the derivation is deterministic, a user who loses a device can re-derive the same App Key on a new one from their recovery phrase. And because the App ID is an input, different apps derive different keys — one app can never read another app's data, even for the same user.

What the indexer does

The indexer verifies your app's identity, manages the approval flow, tracks the user's pinned objects and their encrypted metadata, and coordinates with storage providers — all without ever seeing plaintext data. See Indexers and the Trust & Deployment Model for what it can and cannot see.

Approval failures

Approval can fail if:

  • The request expires before the user approves it
  • The user declines the request (the indexer will not approve it)
  • There is a network or connectivity issue while polling