Apps & API Keys

In Quasar, every integration begins by creating an App. An App acts as an isolated logical container for your application data (indexed transactions, webhooks, analytics), separated by your specific API keys.

🛠️ Creating an App

You manage Apps through the Quasar Management Dashboard:

1. Log in to the Quasar Dashboard .
2. Ensure you are in your target Organization.
3. Navigate to Apps and click Create App.
4. Give your App a descriptive name (e.g. Pulsar Indexer - Production).

Once created, Quasar provisions a pair of credentials: a Secret Key (sk_live_...) and a Public Key (pk_live_...).

🔑 Secret Key vs. Public Key

Quasar provisions two distinct key types designed for different trust environments:

🔐 Secret Keys (sk_live_...)

The Secret Key is a high-privilege credential:

sk_live_YOUR_SECRET_KEY_HERE

[!CAUTION] Never expose your Secret Key in client-side code. Secret Keys act as bearer tokens granting root access to your App’s isolated partition in Quasar. If leaked, unauthorized actors could sync fraudulent transactions or exhaust your organization quota. Keep Secret Keys strictly inside backend environment variables (.env).

Hashing at Rest & IronDomeGuard Resolution

For security, Quasar does not store raw Secret Keys in plaintext inside PostgreSQL:

1. Hashing on Creation: When a key is generated, Quasar computes a cryptographic SHA-256 hash before persisting it to the database.
2. Real-Time Verification: When an API request arrives at the performance tier (api.tuwa.io), the IronDomeGuard intercepts the x-tuwa-secret-key header, hashes the incoming sk_live_... token in real-time using SHA-256, and matches it against the database hash.
3. Redis Metadata Caching: Once resolved, the app metadata (IP whitelists, domain constraints, organization limits) is cached in Redis under {secretKeyHash}:meta for high-throughput evaluation.

BOLA Protection & Key Rolling

• Step-Up Authentication: Revealing an active Secret Key in the Dashboard requires Step-Up Authentication (account password re-verification, plus a 2FA code if 2FA is enabled on the user’s account) to prevent Session Hijacking and Broken Object Level Authorization (BOLA) exploits.
• Rolling Secret Keys: If a key is compromised, you can roll a new key through the App Settings panel. Rolling immediately generates a new sk_live_... token and invalidates the previous key in PostgreSQL.

Edge Propagation: Database invalidation is instantaneous, while Redis edge caches evict old key metadata within up to 60 seconds. After rolling a key in the Dashboard, copy the new Secret Key, update your backend environment variables (.env), and redeploy your backend services.

🌐 Public Keys (pk_live_...)

The Public Key is a non-sensitive identifier:

pk_live_YOUR_PUBLIC_KEY_HERE

Public Keys are safe for inclusion in client-side bundles (Next.js client components, mobile apps, or decentralized frontends).

Resolution & Scope

1. Header Identification: The client sends the Public Key in the x-tuwa-public-key header.
2. Direct Lookup: The IronDomeGuard matches the key directly against the database publicKey column and caches metadata in Redis under {publicKey}:meta.
3. Read-Only Enclosure: Requests authenticated via Public Keys are restricted to read-only queries (such as public transaction tracking or history lookups), preventing unauthorized transaction writes or ledger mutations.