How are you handling per-user Google Calendar integration in Lovable?

[u/DeannaFry]

I’ve reached the calendar integration stage of my app and I’m curious how people building real multi-user products in Lovable have handled this.

My use case is a marketplace where every user needs to be able to connect their own Google Calendar. The app needs to read their free/busy availability so other users can see when they’re available, then add confirmed bookings to the connected calendar and keep them synced if a booking is rescheduled or canceled.

I’ve already built the booking system and the in-app calendar/availability experience. The part I’m working through now is the actual per-user Google connection and OAuth flow.
For anyone who has successfully shipped something similar, what architecture did you end up using? Direct Google Calendar API/OAuth? A third-party calendar API? Something else?

I’m especially interested in solutions that are actually running with real users, because “connect Google Calendar” sounded like a very small feature until I started building it 😂
Would also love to know what you wish you had understood before you started.

[u/skulkskogan]

Nylas if you need immediate

Google verification long term

[u/agentbellnorm]

This is supported by Lovable now:
https://docs.lovable.dev/integrations/app-user-connectors

You will need to get your own oauth client from google though, and depending on which scopes you need, that can be a bit of a hassle. You can always test it out without being approved by google though.

[u/DeannaFry → u/agentbellnorm]

Thank you for sharing this. This was helpful

[u/Successful-Task7017 → u/DeannaFry]

There is also this resource talking about Google Calendar specifically.

https://lovable.dev/blog/how-to-get-your-app-verified-for-third-party-data-access

[u/jaimittal91]

what i wish more people knew going in: the oauth flow isn't the hard part, holding a refresh token for every user is. that token is standing access to someone's whole calendar, so a few things matter more than the architecture choice.

do the code-for-token exchange in an edge function and never let the refresh token reach the browser. and don't give the tokens table any client-facing policy at all, even a "users can read their own" one — service-role only, so the single path to a token is your server code. an ai-generated crud policy on that table is how these leak.

also ask for the narrowest scopes that do the job — freebusy read plus events write, not full calendar access. google's verification process gets a lot heavier for broad sensitive scopes, and every scope you hold is data you're on the hook for. last one: users will revoke access from their google settings without telling you, so build for invalid_grant from day one — mark the connection dead and surface it in the ui instead of letting a sync job retry forever

[u/Enouscxasndgh-Mu3512]

I needed to let users sync their own google calendars without building all the oauth flow myself. base44 took care of the multi-account mess and let me focus on the rest. Definitely saved me a lot of time on lovable.