Exporting Base44 users to CSV, and moving them without password resets

The short version

Base44 lets you export your tables to CSV from the Data page, one table at a time. Its documentation doesn’t describe an export for the Users list, and its privacy page says plainly that app users can’t be exported. What you can read out is each user’s record: ID, email, name, role, whether they also edit the app, and when they joined, plus any custom fields you added. You do that through Base44’s API, a backend function, or an owner-only page in your app.

What you can never take out is a password. That’s why moving users is the hard part of leaving any platform: without the stored password hash, a new system has no way to check the password someone types. The usual answer is a password reset for everyone. Unbase44 avoids it. Each user’s first sign-in on the new app is checked against Base44 once, and from then on your app stores its own hash. Google sign-in comes across too, using your own Google sign-in client.

What a Base44 user record holds

Every Base44 app has a built-in User table. Base44’s User schema docs and its API reference for listing app users document these fields:

A password isn’t among them. Base44’s login documentation says it handles passwords behind the scenes, and nothing in the docs exposes the hashes. The API reference also warns that responses include fields it doesn’t document, so build on the documented ones.

Don’t confuse this with exporting workspace members. Base44’s workspace members page has a download icon that exports a CSV. That list is the people who build apps in your workspace, not the people who use your app.

Three ways to get your user list out

1. Base44’s Apps API

The Apps API has a List app users endpoint. A developer calls it with a personal API key from someone with editor access to the app, and gets back everyone who signed up or accepted an invitation and signed in. You can filter by any field, for example ?role=admin. Two details matter for a complete list:

• People you invited who haven’t signed in yet aren’t included.
• Accounts Base44 added on its own, such as workspace admins, support staff and the short-lived accounts a test run creates, are left out.

The API is marked beta as of October 2026, so its fields and behaviour may change.

2. A backend function

Inside a backend function, base44.asServiceRole.entities.User.list() returns every user, regardless of the access rules on the User table (SDK entities reference). Backend functions need the Builder plan or higher as of October 2026. Base44 also caps a single data request at 5,000 items, so a larger app needs to page through its users.

3. An owner-only page in your app

Base44 restricts the Users list so that only the app owner and collaborators can read it (Choosing who can access your app). If you aren’t a developer, you can ask the AI chat to add a page that lists your users and downloads them as a CSV. Keep that page behind an admin check, because the file is your users’ personal data.

Anything you store about users in your own tables, such as a UserProfile table, exports the normal way: Data, select the table, More actions, Export.

Roles: where they live and what they control

Every Base44 app starts with two roles. Admin can reach the admin-only areas of the live app, and User can use the app without special permissions. You change a role under Dashboard, Users, then select the person and pick a role. Apps can define more roles, either as values of role or as a custom field such as app_role.

Two things are easy to mix up:

• App roles decide what someone can do in the live app. Your tables’ access rules check them, and rules can also check custom user fields, such as limiting each user to records from their own company.
• Collaborators can open Base44’s editor and dashboard. Since 16 February 2026 that has been a separate setting from the app role, though a new collaborator is made an Admin by default.

Because the role is a field on the user record, it travels with the record. Collaborator access belongs to Base44’s editor, so it has no meaning once the app runs elsewhere. After a move, the people who can change the app are the people with access to its repository.

Why passwords are the hard part of any move

A well-run sign-in system never stores your users’ passwords. It stores a one-way hash: enough to check that a password is right, not enough to recover it. Base44 doesn’t export those hashes.

That leaves anyone rebuilding an app elsewhere with three options:

1. Ask everyone to reset their password. Simple, but every user has to act on an email before they can get back in, and some won’t. Rebuilds on another stack, such as Supabase, usually end up here.
2. Switch to sign-in codes or magic links. No password to move, but a different sign-in experience for everyone.
3. Check each password against the old system the first time it’s used. The user signs in as usual, the old system confirms the password once, and the new system stores its own hash. This only works while the old system is still running.

How Unbase44 keeps your users’ passwords

Unbase44 takes the third route. Every user moves to your new app. The first time someone signs in there, their password is checked against Base44 once, and your app then stores its own hash. They type the same email and password they always have, and nobody gets a reset email.

The one condition: keep the Base44 app published until your active users have signed in once. The check needs Base44 to answer. Apps stay live on Base44’s Free plan, and our article on cancelling Base44 gives the safe order for ending the subscription and what stops working on Free. Anyone who hasn’t signed in by the time you finally retire the Base44 app will have to set a new password.

The new app sends its emails, sign-in codes included, through your own Resend account or any SMTP server. While you test it, the new copy runs in test mode and holds outgoing messages, so the Base44 app keeps serving your users until you switch over.

You can see how many users your app has before you connect any account or pay: the free analysis lists them alongside your tables, functions and files.

Google sign-in

On Base44 you set up Google sign-in in one of two ways, according to its login documentation:

• Base44’s default Google sign-in uses Base44’s own Google credentials. The Google window is branded with base44.com.
• Custom Google OAuth uses your own Google Cloud client, so people see your domain. As of October 2026 it needs the Builder plan or higher, a custom domain, and a payment method on your Google Cloud project, and Base44 says Google’s approval can take up to 5 days.

When the app moves, Google sign-in comes with it, set up with your own Google sign-in client. The default credentials belong to Base44, so a moved app needs a client of its own. The app’s page walks you through creating it in a few minutes.

If your app also offers Microsoft, Facebook, Apple or single sign-on, plan those separately. This article covers email-and-password and Google sign-in.

When Google login or password reset isn’t working on Base44

Most sign-in problems on a Base44 app have a documented cause:

• Google still shows base44.com after you set up your own client: Google hasn’t approved your project yet. Base44’s SSO page says your branding appears once it does.
• Custom Google sign-in fails: check that the redirect URI in Google Cloud is exactly https://app.base44.com/api/apps/auth/callback, that your domain is an authorized JavaScript origin, and that your home page, privacy policy and terms are public, which Google requires.
• Google sign-in fails in an Android app from Google Play: add the Google Play app-signing SHA-256 fingerprint to Base44 (app store guide).
• “Invalid login” with the right password: the app is usually set to Private and the person wasn’t invited. An unverified email or an expired session gives the same error.
• Email and password isn’t offered at all: turn it on under Dashboard, Settings, Authentication.
• The reset email doesn’t arrive: ask the person to check spam and allowlist app@base44.com, then resend. Base44’s last resort is removing them from Users and having them sign up again.
• The reset link opens a blank page: on apps with custom login pages, the page must be at exactly /reset-password, because the link in the email is fixed to that path. Reset links work once; after that, the person requests a new one.

A checklist before you move your users

• Export your user list for your own records, using one of the three ways above.
• Export any table that holds user data, such as profiles or orders, as CSV.
• Note which sign-in methods are on under Authentication.
• If you use custom Google OAuth, note the Google Cloud project it lives in.
• Plan to keep the Base44 app published until your active users have signed in on the new app once.