How to add Google Calendar or Outlook connections to a Lovable, Bolt or Replit app

Two kinds of calendar connection

App builders offer two different things under the word "connector", and only one of them fits a calendar feature.

• The builder's account. You connect your own Google account once. The app reads and writes your calendar. Fine for an internal tool or a booking page for one person.
• Each user's own account. Every person who signs up connects their own Google or Microsoft calendar, and the app acts on their data only. This is what a scheduling product, a CRM or an assistant needs, and it means a full OAuth setup: an OAuth app registered with Google or Microsoft, a consent screen, stored refresh tokens, and a way to reconnect.

Lovable

Lovable's Google Workspace connector covers Google Calendar, and is the first kind: "This connector uses a single shared Google account for everyone who uses the app." Lovable workspace admins or owners manage it.

For the second kind, Lovable has app user connectors, which "let each end user of your published Lovable app connect their own third-party account." Google Calendar and Microsoft Outlook are both supported.

What you get, and what you still do:

• You register the OAuth app with Google or Microsoft and add its details to a client you configure once for your workspace.
• Lovable keeps the tokens, "stored encrypted in the connector gateway," and refreshes access tokens itself.
• A dead refresh token is your code's job. The gateway "answers with a 401 error whose type is credential_refresh_token_expired," and your app has to ask the user to reconnect.
• Plans. Builder access is on all plans. Offline access is always on for Free and Pro; on Business and Enterprise it is off by default, under Advanced settings.

On Google, Lovable notes that "Your Google app can stay unverified," with a catch: people connecting a Google account may see the unverified app screen. The OAuth callback is on Lovable's domain, and "You cannot verify lovable.dev, because you do not own it." Google's limits for unverified apps, below, still apply to your Google app.

Replit

Replit's connectors are the first kind. "Connections are tied to your Replit account and persist across all your apps." Connect Google Calendar once and every app you build reads that calendar.

• Most connectors require a Core, Pro or Enterprise plan.
• "Configuring a custom OAuth app requires an Enterprise subscription."
• The pages we read don't describe a way for each user of a published app to connect their own account.

For per-user calendars on Replit, you write the OAuth flow yourself: your own Google Cloud project and OAuth client, with the client secret kept in the app's Secrets.

Bolt

Bolt's connectors feed Bolt while it builds: "When you turn on a connector, Bolt adds its data to your project's context." There is no Google Workspace connector. For one, Bolt says to "set up a custom MCP server." Either way, that is context for Bolt, not a calendar connection for your users.

For Google sign-in, Bolt's Google SSO guide has you create your own OAuth app in the Google Cloud Console, on a Bolt database or a connected Supabase project. Two notes from that guide matter for calendars too:

• Testing status "limits sign-in to up to 100 users."
• "Google's OAuth flow blocks iframes, so you need to test using your published site rather than in the Bolt Preview window."

Supabase Auth's Google sign-in is not a calendar connection

Lovable and Bolt apps usually sign users in with Supabase Auth. Adding a calendar scope to Google sign-in looks like a shortcut. It gets you a first access token and leaves the rest to you.

const { data, error } = await supabase.auth.signInWithOAuth({
  provider: 'google',
  options: {
    scopes: 'https://www.googleapis.com/auth/calendar.events',
    queryParams: {
      access_type: 'offline',
      prompt: 'consent',
    },
  },
});

What Supabase's docs say about the Google tokens:

• "Google does not send out a refresh token by default." You need access_type: 'offline' and prompt: 'consent', which shows the consent screen at every sign-in.
• "On initial sign-in, you can extract the provider_token from the session and store it in a secure storage medium." The same goes for provider_refresh_token.
• "Supabase Auth does not manage refreshing the provider token for the user."
• "Provider tokens are intentionally not stored in your project's database."

So you capture both tokens at sign-in, store the refresh token encrypted, call Google's token endpoint when the access token expires, and handle the day the refresh token stops working. A Supabase discussion titled "How can I refresh the provider_token?" has been open, unanswered, since July 2021.

Google's limits apply everywhere

None of these platforms changes Google's rules for your OAuth app. Calendar scopes are sensitive, so:

Google also allows "100 refresh tokens per Google Account per OAuth 2.0 client ID".

For Outlook, Microsoft's default consent policy keeps users in work accounts from approving Calendars.Read or Calendars.ReadWrite, so many business users will need their administrator first. That holds whichever builder you use.

How Pyas handles it

Pyas gives your app per-user calendar connections without registering OAuth clients of your own. With Pyas Auth, users approve Pyas on Google's, Microsoft's and Zoom's own consent screens, and Google, Microsoft and Zoom have already verified it, so there is no Google review on your side. That is on every plan; the free plan covers 3 connected accounts. Microsoft's default consent policy can still require an administrator to approve calendar access for work accounts, with Pyas Auth too.

Your app's server code calls one API for Google Calendar and Outlook. Pyas stores and refreshes the tokens. GET /v2/accounts/{accountId}/status says whether an account works and, if not, why and the fix; the connection.broken webhook fires when one stops; a connect session created with the account's accountId opens PyasConnect on that account, so the user reconnects inside your app. When you want your own name on Google's consent screen, switch Google to Native Auth.

Lovable, Bolt and Replit can each add Pyas's hosted MCP server by its address. Their agents then get the server code for each task from Pyas, with the key kept as a secret on the server. The steps for each are in the docs: Lovable, Bolt, Replit and v0.

Common questions

Can I use Lovable's Google Workspace connector for my users' calendars?

No. It uses one shared Google account for everyone. Use an app user connector, with your own OAuth app, or a service that handles per-user connections.

Why does Google sign-in fail in Bolt's preview?

Google's OAuth flow blocks iframes. Test on the published site.

I added the calendar scope to Supabase's Google sign-in. Why does calendar access stop working?

Google access tokens expire, and Supabase doesn't refresh provider tokens. Request offline access, store provider_refresh_token yourself, and refresh against Google.

Do I need Google's verification if my users connect through Lovable?

Your Google OAuth app is still yours. Unverified, it shows the warning and stops at 100 new users; verified, it doesn't.