# Register your app — from the preview vault to an app that's yours

The [Get Started](./vault-apps.md) walkthrough runs a vault app straight from the **preview** vault, with no account and
no registration: anyone can open `vault?app=<origin>` and the SDK works. That's deliberate — you build and try the whole
model before you register anything. This page is the other half: how a vault app stops being a preview and becomes **a
hosted app that belongs to you** — a tenant that spends credit, an app identity the platform can attribute rooms to,
and, when you want them, rooms only *your* users may join.

> **Status.** Tenant onboarding and the tenant-keyed `/v1` API are **private beta** (invite-gated). The **owner-key app
> registry** — how an app claims authority over its rooms — is **built, opt-in, and not yet enabled in production**. The
> hosted vault binding *your origin* as a verified first-party app is the **next milestone**; today the vault is the open
> preview origin and accepts any `?app=`. Everything below is written so you can tell what you can do now from what is
> coming.

There is no "Witbitz account" for your end users to create — the platform stays content-blind and account-free on the
user side. Registration is about **you, the builder**, not them. It has up to three steps; most apps need only the first.

## Step 1 — Become a tenant (do this first)

A **tenant** is your builder identity on hosted Witbitz. You get one by redeeming an access code:

```text
https://witbitz.chat/access
```

It mints a **tenant key pair**, shown once:

| Key | Prefix | Use |
|---|---|---|
| Secret | `wsk_` | server-side only; authenticates your backend to `/v1` |
| Publishable | `wpk_` | browser-safe; identifies your tenant for public reads — it does **not** authenticate an end user |

No access code yet? Email **hello@witbitz.chat**. Once you hold keys, `GET /v1/tenant` reports your tenant and its
**roles** — an `app` (builds a product, spends credit) or an `issuer` (holds the customer relationship), or both. A vault
app is an **`app`**.

Read: **[Hosted private beta](./hosted-private-beta.md)** · **[Platform API](./api-reference.md)** ·
**[Issuer vs app](./the-issuer.md)**

For a personalization-only vault app like Beacon, this is usually all you need: a tenant so your usage is metered to you
instead of the shared preview, and secret-key access to any `/v1` surface your backend calls.

## Step 2 — Register the app (when you want rooms that are *yours*)

A vault app creates a room under the hood for each personalization. By default a room's authority is its link — whoever
holds it. The moment you want *"every room in my app is only for my people"*, you register an **owner key** for your app,
and rooms minted under it are provably yours.

The mechanism is the **owner rule**. In short:

1. **Mint an owner key** (an asymmetric keypair only you hold) with the operator CLI, or self-register it against your
   app id with `op:'register-owner'` — a create-once call gated by a platform-signed grant scoped to your app + key id.
2. **Pin the public key** — baked into your app and published at a well-known URL — so the certified render and other
   members can independently verify that a room's policy was really signed by *you*.
3. Now only your credential can mint a room stamped with your app (**room-genesis**): a copied policy on someone else's
   room won't verify, so nobody can stand up a look-alike of your app.

Hosted, this registration **is** tenant onboarding proven with your tenant key; on-prem it's local config. It is built
and tested end-to-end, opt-in, and inert until you turn it on — an app that never registers behaves exactly as it does
in preview.

Read: **[Owner-governed rooms](./the-owner-rule.md)**

## Step 3 — Govern who joins, and at what tier (optional)

With an owner key registered, you can attach a signed **App Policy**: a ladder of tiers (`open` → `member` → `gold`),
each mapping an admission rule (anonymous, or an IdP claim from *your* identity provider) to a set of capabilities and
limits. The certified render verifies the policy's signature every turn and admits each federated sign-in at the tier
its token's claim earns — the client can't self-promote. The same table doubles as your pricing surface, since per-tier
limits ride the platform's existing metering.

Read: **[Owner-governed rooms](./the-owner-rule.md)** · **[Delegated authority](./delegated-authority.md)**

## What's registered, and what's still preview

| Capability | Status |
|---|---|
| Tenant account + keys (`/access`, `/v1/tenant`) | Private beta — real, invite-gated |
| App owner-key registry (`register-owner`, room-genesis, App Policy) | Built · opt-in · not yet enabled in production |
| The hosted vault treating your registered origin as a **verified first-party app** — your brand in the trust chrome, `?app=` resolving to a registered app id rather than an arbitrary origin | **Next milestone** — the preview vault accepts any origin today |

So: **becoming a tenant is a real step you can take now** (invite-gated); **registering an app's owner key is a built,
opt-in primitive**; and the vault's first-party binding of your specific origin is the honest gap between this page and
[Get Started](./vault-apps.md). Until it lands, run your app in the preview vault and register your tenant so your usage
and any owned rooms are attributed to you.

## Next

- **[Get Started — vault apps](./vault-apps.md)** — the app side: build Beacon in ~15 lines.
- **[Hosted private beta](./hosted-private-beta.md)** — what hosted operates, sees, and cannot see.
- **[Owner-governed rooms](./the-owner-rule.md)** — the full registration + policy + enforcement model.
- **[Platform API](./api-reference.md)** — the tenant-keyed `/v1` surface your backend calls.