# Platform Your dashboard for avatars, API keys, and usage. This is where you find the IDs and keys your app needs. ## What's in the Platform 🎭 Avatar Library Browse our growing collection of pre-built, optimised Rive characters. Publish one to your account to get the unique ID you pass to your SDK config. ⬆️ Custom Uploads Upload your own animated characters. Design them in-house and bring them to life with the SDK. 🗝️ API Key Management Create separate keys for dev, staging, and production. Monitor usage and session quotas in real time. 📊 Analytics Session duration, interruption rate, error rates — understand how users interact with your avatars and tune accordingly. ## Just want to try it? Use `"default"` Every code example in these docs uses a special avatar ID: ```tsx avatar: { avatarId: "default" } ``` `"default"` is a public demo avatar resolved on our server. Drop it into your config and you'll have a talking avatar on screen in minutes — no publishing, no setup. It's perfect for prototyping and following the [Quickstart](/docs/quickstart). > `"default"` is meant for trying things out. When you ship to production, publish > your own avatar (below) and use its ID so you control its look, voice, and > personality. ## Getting your own avatarId Your own avatar ID isn't copied from the library directly — you **publish** an avatar to your account first. Publishing forks the library character into a copy you own, which is the avatar your app actually loads. ### Step 1 — Pick an avatar Open the **[Platform dashboard](/platform)** and choose a character from the library. Free avatars are available on every plan; some premium avatars require a paid plan (see below). ### Step 2 — Customise it (optional) In the builder you can tune the look, voice, brain, and personality. Skip this if the defaults are fine — you can always come back and edit later. These saved settings act as the avatar's defaults; anything you pass in the SDK config at runtime overrides them (see [how settings are resolved](/docs/sdk/react/configuration#how-avatar-settings-are-resolved)). ### Step 3 — Publish Click **Publish**. This creates your own copy of the avatar and assigns it a unique ID. The first publish forks a new avatar; publishing again updates the same one. ### Step 4 — Copy your avatar ID Open the **Publish** panel — your avatar ID is shown there with a copy button. That's the value you pass to `avatar.avatarId`: ```tsx const config = { getSessionToken: async () => { const res = await fetch("/api/avatar-token"); const { sessionToken } = await res.json(); return sessionToken; }, avatar: { avatarId: "your-published-avatar-id", // Copied from the Publish panel }, }; ``` ## Free vs. paid avatars The library has free avatars and premium (paid) avatars. - **Free avatars** — publish and use them on any plan, including Sandbox. - **Premium avatars** — require a paid plan. If you try to publish one on the Sandbox plan, the Publish action is blocked and prompts you to upgrade. > Plan limits are enforced on our servers, so a premium avatar can't be used > without a qualifying plan even if you have its ID. Manage your plan from the > **[Platform dashboard](/platform)**. ## Deploying an avatar Publishing gives you an ID for your own code. To put the avatar on a site with **no backend** — a Framer site, a landing page — create a **deployment** instead: a public, domain-locked credential with its own monthly minute budget. Open the avatar and use the **Deploy** tab. See [Framer](/docs/sdk/framer/overview) for the full flow, or [API keys](/docs/platform/api-keys) for how deployments compare to the other credentials. ## API key best practices > **Keep live keys server-side.** Use them on your backend to mint short-lived > session tokens via `getSessionToken`. Create a **separate live key per app or > environment** so you can revoke one without stopping everything else. Rotate > immediately if a key is exposed. ```bash # .env — server-only. No NEXT_PUBLIC_ prefix, or it lands in your bundle. AVATAR_FACTORY_KEY=af_live_xxxxxxxxxxxxxxxx ``` There are only two API key environments — `af_test_*` and `af_live_*`. "Staging" is not a separate key type: create a second **live** key and name it after that environment. For local development, use your **test key** (`af_test_*`), which the SDK accepts directly as `apiKey` and which draws on a separate free allowance. Full details in [API keys](/docs/platform/api-keys). ## Ready to integrate? Open Platform → Back to Quickstart