> ## Documentation Index > Fetch the complete documentation index at: https://docs.base44.com/llms.txt > Use this file to discover all available pages before exploring further. # Step 1: Collect the keys > Step 1 of the Base44 white label setup skill: get the workspace ID, save the personal access token as a secret, and confirm it works. This is step 1 of the Base44 white label setup skill. Follow it on the path you picked: Local, Cloud, or App builder. Read first: [tenancy and credentials](https://docs.base44.com/developers/white-label/tenancy-and-credentials.md), [personal access tokens](https://docs.base44.com/Workspaces/Personal-access-tokens.md), and [plan requirements](https://docs.base44.com/developers/white-label/overview.md). The person supplies two things: the workspace ID and a personal access token. You don't need to install anything or sign them in. ## Get the workspace ID The workspace ID isn't a secret, so the person can paste it into the chat. If the message that started this setup already includes a workspace ID, as the prompt copied from **White label** → **Settings** does, use that one and skip to step 4. 1. Ask the person to open the workspace their integration builds in, not their personal workspace. 2. Ask them to open the workspace menu at the bottom left, click **Settings**, and copy the address from the browser's address bar into the chat. The main **Apps** page address doesn't include the ID. 3. From what they paste, keep only the characters between `/workspace/` and the next `/`. 4. Check that it's exactly 24 characters, each a digit or a letter from a to f. If it isn't, ask again and show them what the address looks like. ## Prepare the secret Set up the token's place before you ask the person to create it, so they never have to hold it anywhere unsafe. * **Local:** Create the environment file and confirm it's listed in `.gitignore` before the person pastes anything. * **Cloud:** Name the exact setting and screen in the hosting provider where it goes. * **App builder:** Create the secret with the app builder's secret request feature, or tell the person the exact secret name and where the secrets screen is. Name the secret exactly `BASE44_WL_TOKEN`, even if the project's example file suggests another name, and make the code read that name. Store the workspace ID as `BASE44_WL_WORKSPACE_ID`. Fill in every value that isn't a secret yourself, including Base44's host, `https://app.base44.com`. The personal access token works on every plan, and it's always sent as `Authorization: Bearer `. Some plans also include workspace API keys, which work instead of the token for embedding and live updates. If the project already uses a workspace API key for those, keep it. A workspace API key is sent as `api_key: `, except for live updates, which take `Authorization: Bearer `. ## Create the token 1. Before you show any form or link, tell the person in one sentence what the token is for: "This token lets your platform build apps in Base44 for your users. It stays on your server, and your users never see it." 2. Ask them to create a [personal access token](https://docs.base44.com/Workspaces/Personal-access-tokens.md#creating-an-access-token) in the integration's workspace, with the access and permission that [authenticating as the integration account](https://docs.base44.com/developers/white-label/tenancy-and-credentials.md#authenticating-as-the-integration-account) lists. Give them the click path, not only the link. 3. Ask them to paste the token into the place you prepared, not into the conversation. 4. Put the workspace ID in the same place yourself. If the person says they saved the token on the secrets screen, such as **Dashboard → Secrets** in Base44, accept that and continue. Don't ask them to show it to you. The same token also signs end users in to [embedded apps](https://docs.base44.com/developers/white-label/embed-the-app.md) and opens [live build updates](https://docs.base44.com/developers/white-label/live-updates.md), so you don't have to create a workspace API key. ## Verify the token **App builder path:** Publish the app once after the token is saved, before you run the check. Saved secrets don't reach the server until the app is published. Guide the person through publishing if you can't publish yourself. Call [List apps](https://docs.base44.com/api-reference/list-apps.md) from the server with the token and the `X-Active-Workspace-Id` header, and report only the status code, never the token. On the App builder path, write a small backend function that makes this call and returns only the status code, then run it. | Response | What it means | Your next action | | :- | :- | :- | | Success | The token works in the integration's workspace. | Continue to step 2. | | Token rejected | The token is wrong, expired, or from another workspace. | Ask the person to create a new token in the integration's workspace, with the access and permission listed above. | | Permission refused | The account's role can't build apps. | Ask a workspace owner to [change the role](https://docs.base44.com/Account-and-billing/Managing-your-workspaces.md#changing-a-members-role) to Editor or above. A role error is a permissions problem, not a plan problem. | | Secret is empty or not found | The secret's name doesn't match what the code reads, the person saved it somewhere else, or, on the App builder path, the app hasn't been published since. | Check that the secret is named exactly `BASE44_WL_TOKEN` and the code reads that name. On the App builder path, publish again and rerun the check. | You don't check the plan or role up front. Later, if a call is refused because of the plan, skip that feature, tell the person what you skipped, and say they don't need to do anything about it. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.