Skip to main content
This is step 3 of the Base44 white label setup skill. Write the code yourself, following the linked pages. “Server code” means the place your path keeps it: the project’s server code, or the app’s backend functions on the App builder path. White label API calls go in server code. Pages call your server code, never Base44 directly.

​
Build the app-building chat

  • Read: The build turn, custom instructions, and common APIs.
  • Ask: “Should each app get platform-specific context, such as which of your APIs it can call?”
  • Default: Build it into the platform’s own UI, where its users already are. One chat per app, with build progress, the agent’s questions, a preview, and follow-up messages. Use the starter as reference code, not as the product. No custom instructions until the person names a need.
  • Verify: Read each created app back and confirm every field you sent applied.
  • Skip when: Never. This is the part of the integration the person’s customers use.
Write the chat for the person’s customers, not for developers:
  • Show progress in plain language. Say what the agent is doing in words a customer understands, such as “Designing your booking page.” Never show status codes, field names, tool names, or raw API states.
  • Show a loading message while the preview loads, such as “Loading your app preview…”, so the panel is never blank.
  • List apps by name. Show each app’s name from Base44, not the first words of the prompt that created it.

​
Set up user access

  • Read: Tenancy and credentials.
  • Ask: “How do people sign in to your platform today?” On the App builder path, don’t ask: the app’s own sign-in is the platform’s sign-in.
  • Default: Reuse the platform’s existing sign-in, so signed-in people reach the app-building chat with no extra step.
  • Do: Write the code on top of the platform’s existing sign-in.
  • Verify: A signed-in person reaches the app-building chat. Open the published app signed out, such as in a private window: the platform’s sign-in page must load, not an error or a separate sign-in for the integration.
  • Skip when: Never. The chat sits behind the platform’s sign-in.
Don’t add access-key forms, access-file uploads, or private-link requirements unless the person chose that access model.

​
Record app ownership

  • Read: Who owns the apps.
  • Ask: “Should people see only the apps they built, or share apps with their team?”
  • Default: Each person sees only their own apps.
  • Do: Store ownership in the platform’s database. On the App builder path, that’s a data table in the app, such as an entity with the app ID, the app name, and the signed-in person who created it.
  • Verify: Sign in as two different people. Neither can list, open, or change the other’s apps.
  • Skip when: Never for a platform with more than one builder.

​
Embed the app

  • Read: Embed the app.
  • Ask: “Should the apps open inside your platform, and should they know who’s looking at them?”
  • Default: Embed in an iframe, signed in as the person viewing it, with the integration’s personal access token.
  • Do: Write the server code following the embed page. If the workspace has an embedding policy, guide a workspace owner or admin through adding the platform’s site.
  • Verify: The app loads in the iframe already signed in, with no Base44 sign-in page.
  • Skip when: The apps open as links, or they don’t need sign-in.

​
Save conversations

  • Read: Read conversation messages.
  • Ask: “Should people come back to the apps and conversations they started earlier?”
  • Default: Store each person’s app IDs with the ownership record, and read the conversation back from Base44 when they return.
  • Verify: Refresh the page and sign in again. The person’s apps and conversations are still there.
  • Skip when: People don’t need to return to apps they started earlier.