Base44 Review: App Access, API Tokens and Running Costs

Choose Base44 for a bounded workflow you can inspect

Base44 is relevant for a prompt-led app with a bounded business workflow: a tracker, a dashboard or a simple portal. Its managed backend brings data, user management and hosting into the same creation flow.

I would keep the first build small enough to explain who owns each record, what a user action costs and which services remain outside your source repository.

Compare the workflow you would maintain:

• Wix for a public service website with routine content edits.
• Lovable for another conversational app workflow.
• Replit for a more visible development workspace.

Keep the tracker trial, but test the denied action too

Start with a project tracker with an administrator and two team members, plus a notification on one update. These are suggested tests based on documentation, not results from a Base44 account.

• Let member A create and update an assigned record.
• Give member B the URL or identifier of A’s restricted record.
• Try both reading and updating that record as B.
• Confirm the administrator can perform the action their role permits.

Pass when the data rules enforce the intended boundary. A hidden edit button does not prove that a restricted write fails.

Base44’s permissions editor separates Create, Read, Update and Delete. The documented route is Dashboard → Data → select a table → Permissions.

A rule detail matters here: matching any one rule grants access. Check for a broader rule that still permits the action after you add a narrower owner rule.

A limited customer portal can use the same trial with two customers and one administrator. Start with one request or document workflow before importing real customer records.

Audit external scripts after the account-key retirement began

If an external script reads or changes your app, I would check its authentication before spending another prompt on the interface.

The developer changelog’s September 23 entry now says that, since October 15, 2026, account API keys can no longer be viewed or created and existing keys are being switched off gradually.

That is a current migration requirement, not evidence that every Base44 app stopped working on October 15.

The Apps API reference rejects a personal access token sent in the old api_key header.

The Monitoring API reference still requires a workspace key with the monitoring:read permission, apart from its health check. Do not replace every api_key header across the workspace. Classify the endpoint first.

My practical approach is to make an inventory of callers, rather than search-and-replace a credential name:

• Record the endpoint and the script, automation or service calling it.
• Identify whether the existing credential is an account key, workspace key or another authentication type.
• Record the app, workspace and permitted action.
• Name the person responsible for the next credential change.

This migration concerns the documented external API authentication. It does not establish that your normal app login needs replacing.

Example: prove the morning tracker sync in its actual runner

Suppose a scheduled job copies tracker updates to another system. This is a proposed acceptance test, not a migration I have performed.

1. Identify the exact API family and the records that job should read or write.
2. For a PAT-based caller, create a token under Workspace settings → Secrets → Personal access tokens. Limit it to the intended app and actions; keep the value in the runner’s secret store.
3. Update the request header as well as the credential. Use the actual scheduled runner to process a small, identifiable test record.
4. Reconcile the destination record, expected fields and last successful run. Save the status and a redacted request description.

A successful request in a separate API client does not prove that the scheduled runner has received its new secret.

If the runner fails, check the header, workspace, selected app, permitted action and token status before widening access.

Pass when the real job processes the intended record without granting unrelated access.

The token guide also says a personal token stops working when its creator leaves the workspace. Record that dependency in the handoff.

For team-owned integrations, confirm the supported credential in that API’s current reference before choosing a replacement. A workspace key documented for Monitoring is not proof that the Apps API accepts it.

Check the running workflow’s credits with the right account

The everyday user action also affects the budget. Message credits cover AI building activity; integration credits cover built-in services used by the running app.

Keep the tracker notification in the trial. Compare usage before and after the intended action, and record the app, time range and source of consumption.

An editor’s usage view cannot establish the whole workspace’s cost.

Current documentation gives owners and admins workspace-wide visibility, while editors see their own usage and viewers cannot open Credit usage.

Ask the owner or admin to check Workspace settings → Credit usage for the relevant period. Distinguish building activity from notifications, AI actions and other runtime services.

Use observed consumption to estimate a representative session. Do not treat the documentation’s illustrative credit amounts as a guaranteed quote for every action.

Retain source without assuming the backend has moved

A paid GitHub sync can retain source, but independent operation still requires reviewing backend dependencies and data migration.

The GitHub integration requires Builder or higher, and only the app owner can connect or reconnect the repository.

Ask the future maintainer to retrieve the source, identify its service calls and make a small follow-up change. List the data, authentication, files and integrations that change still needs.

For local changes to sync back, the documentation requires a branch named main. After syncing, Publish makes the changes live for users.

Verify the intended deployed revision rather than assuming a repository update has already reached customers.

Save your recovery point before connecting GitHub. Base44 says Version History cannot restore versions from before the GitHub integration; those older versions are not in the connected repository.

That constraint changes the handoff sequence. Keep a recoverable record before the connection, then confirm which repository versions the maintainer can actually restore.

For a destination outside the managed platform, use the code-export checks to separate source retrieval, a working deployment and service independence.

Next step: accept one user action and one external dependency

My next step would be the tracker trial above, with its notification and any external job kept in scope.

Before adding features, save:

• One permitted action and one denied cross-user read or write.
• Runtime usage checked by an account with the required visibility.
• The external caller’s API family, credential owner and successful-run evidence, if the workflow has one.
• The repository revision, publishing responsibility and managed services still required.

Continue when the intended workflow works, the restricted action fails and the next maintainer can repeat the checks. If your app has no external API caller, skip the token migration test and document that scope.