Skip to main content
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, personal access tokens, and plan requirements. 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 <token>. 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: <key>, except for live updates, which take Authorization: Bearer <key>.

​
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 in the integration’s workspace, with the access and permission that 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 and opens live build updates, 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 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. 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.