Leaving Base44? Keep Gmail, Calendar, and Dropbox Working

GmailEach user's mailbox

Google CalendarEach user's calendar

DropboxEach user's files

You built a CRM where every salesperson connects their own Gmail. Or a planner that imports each user's Google Calendar. Or a client portal where people browse their own Dropbox files. These connections are part of the product: without them, moving the pages and database would leave your users with half an app.

They are also an easy dependency to overlook. A “Connect Google Calendar” button lives in your code, but the service keeping that connection alive may belong to Base44.

Staticbot now supports per-user Google Calendar, Gmail, and Dropbox integrations in Base44 migrations to your own Supabase. The connection service runs in your project, using OAuth credentials you control.

One company inbox is different from every user's inbox

A shared connection lets the whole app use one account: a company mailbox for notifications, for example. A per-user connection lets Alice send from Alice's Gmail and Bob send from Bob's. Their permissions and connections have to stay separate.

Base44 supports both models, as its connector documentation explains. In both cases, Base44 runs the connection service. Exporting your app's code and data leaves that service behind.

Whose credentials are you actually using?

There are three separate things here: the person's Google or Dropbox account, the OAuth application asking for permission, and the saved authorization that lets your app keep working after that person closes the consent window.

Some connections run under an OAuth application registered by Base44. You authorize your account through Base44's app credentials, which you cannot take to another host. You will need to register your own OAuth application for the migrated app.

Other configurations already use an OAuth application you registered yourself. Base44's current app user setup asks the builder for their own client ID and secret. In that case, you own the OAuth app, while Base44 manages the users' saved connections. Owning the client does not make those saved connections part of a database export.

What changes with Staticbot

For supported Base44 connectors, Staticbot carries the connection behavior over to your Supabase: each signed-in user connects their own account, the app can keep using that authorization as access tokens expire, and the user can disconnect it again.

The small service that handles this runs in your Supabase project, with its source in your repository. Users' connection tokens are stored encrypted there. Your existing app's supported connection calls keep working through the migration's compatibility layer.

You supply your own provider app credentials and configure the callback address shown during setup. Once configured, these integrations run on your Supabase without requests passing through Staticbot.

Your frontend can be hosted separately, including on your own AWS or Cloudflare account. The connection service stays with the backend you own.

Which apps does this let you take with you?

• Personal planners and scheduling tools: each user connects Google Calendar to import events or use the calendar actions your app implements and the user approves.
• CRMs and email assistants: each salesperson connects Gmail for their own inbox, drafts, or sending workflows, within the permissions granted to your app.
• Client portals and document workflows: each client connects Dropbox so your app can browse or work with the files their authorization permits.

What you and your users still need to do

1. Review the connections your app uses. Check the compatibility findings for the provider and whether the connection is shared or per user. Google Calendar, Gmail, and Dropbox are the supported per-user providers covered here; other providers need a separate review.
2. Configure an OAuth app you own. Reuse a suitable existing client, or register a new one if the old connection used Base44's credentials. Add the new callback address and provide the requested values through App secrets.
3. Check provider approval and permissions. Confirm that the client is approved for the users and actions you intend to support.
4. Test the actual workflow. With a test account, connect, use the calendar, mailbox, or file action, and disconnect. Verify with separate users that each reaches the right account. Confirm the published configuration before reopening a live app.
5. Tell users to reconnect after the move. Their app accounts and imported application data are separate from permission to access Google or Dropbox. Signing back into the app does not restore the old provider authorization.

Calendar access can require sensitive-scope verification; Gmail inbox access can involve restricted scopes and a security assessment, depending on what the app does. Sending email alone has different scope requirements from reading a mailbox. Check Google's verification guidance and Gmail scope reference before choosing a live migration date.

For an earlier Staticbot migration, ask us to check whether the connection service is installed before asking users to reconnect.

Does Lovable have the same limitation?

Lovable's managed app user connectors store user authorizations in its connector gateway, outside your Supabase project. Those connections need a separate migration plan; the automatic connector replacement described here currently covers Base44.

If your Lovable integration already runs in your own backend functions, the migration review instead focuses on carrying over its credentials, updating callback URLs, and testing existing user connections on the new backend.

Check your app's connections before you move

Start with the Base44 migration guide and its compatibility review. For an app with active users, use the live-migration checklist to plan setup, verification, and the reconnect message before the domain switch.

Check your Base44 app with Staticbot.