Build · founder · 9 min read

Your app wants your users' Google data. Here's the review nobody budgets for.

Connecting each user's own account is now a setting in Lovable. Passing Google's verification still isn't. What sensitive and restricted scopes cost you.

Published August 26, 2026 ·

lovable oauth integrations launch security

There’s a feature almost every B2B app eventually needs: your customer connects their own Google Calendar, or their own Slack, or their own HubSpot, and your product acts on their behalf inside it. Not your account — theirs, with their permissions.

Until recently that was the wall where non-technical founders stopped. You had to build an OAuth flow, store refresh tokens without leaking them, keep the connection alive when the user isn’t logged in, and route every API call under the right identity. That’s a real engineering project, and getting it subtly wrong is how you end up on a breach blog.

Lovable’s app user connectors collapsed most of that into a settings screen, and the coverage has been widening fast — GitHub landed on August 24, Amazon Redshift on August 19, Google Workspace earlier. Credentials sit server-side in Lovable’s gateway; your generated app never touches them.

So the hard part is solved. Except the hard part was never really the code.

The part the platform can’t do for you

On August 20, Lovable published a walkthrough of one builder’s Google OAuth verification — Matthew Canaday’s SkyRingAI, an AI phone receptionist that books jobs onto a business owner’s Google Calendar. It’s worth reading, and the reason it matters isn’t the click path. It’s the framing: responsibility here is split three ways, and only one of the three is Lovable’s.

Lovable handles the technical connection. You decide what data gets accessed and justify it. Google decides whether you’re allowed. That last party has a review process, a queue, and — in one tier — an annual invoice.

Nobody puts that on the launch timeline the first time.

Scopes are the whole game

A scope is a single permission: “see when this calendar is busy,” “read this person’s email,” “create files in this Drive.” When you add scopes in Google Cloud Console, Google sorts them into three buckets, and which bucket you land in determines everything that follows.

Non-sensitive — basic sign-in: name, email, profile picture. No data-access verification. If you want your app’s name and logo on the consent screen instead of a raw URL, you still need brand verification, but that’s a light process.

Sensitive — private user data, or the ability to act on it. Reading calendar events is the canonical example. Google reviews why your product needs the access and where in the app that functionality actually appears. Google’s published estimate is up to 10 days. Treat that as an estimate.

Restricted — broad access to a user’s data. gmail.readonly sees every message. drive.readonly sees and downloads every file. Restricted scopes trigger a separate security assessment under the CASA framework, conducted by a Google-empanelled assessor, and you repeat it every twelve months.

Google doesn’t charge you for the assessment. The assessor does. Reported figures land roughly in the $500–$4,500 range depending on tier and how your app is architected — a self-service scan at the low end, a full penetration test at the high end. Nylas has a useful breakdown if you want detail.

The mistake this creates

Here’s the trap, and it’s the single most useful thing in this article: grabbing an extra scope “in case we need it later” can move your entire app into the tier with the recurring paid audit.

You’re building a scheduling tool. You add calendar.events because you need it. Then you think — we might want to email confirmations from the user’s own address, let’s grab Gmail while we’re in here. You just converted a 10-day review into a security assessment with an annual renewal, for a feature you haven’t built.

SkyRingAI asked for calendar permissions and nothing else. That wasn’t modesty. That was the difference between two launch timelines.

The discipline: pick scopes per shipped feature, never per roadmap. Adding a scope later means going back through review — annoying, but survivable, and infinitely cheaper than carrying an audit you didn’t need.

What review actually asks of you

Assume you need a sensitive scope. Here’s the shape of it, in the order the work happens.

Write the feature down before you open Cloud Console

For each thing your app does with the provider’s data: what the user can do, which product supplies the data, whether you read / create / update / delete, and why a narrower permission would break the feature. You will reuse this list four times — choosing scopes, writing the privacy policy, recording the demo, and answering the reviewer.

Build it end-to-end first

Reviewers look at the live product. The consent screen, the branding, the scopes, and the working feature all have to match what’s in the application. A half-built flow with a “coming soon” button is a rejection.

Publish a real homepage on a domain you own

Publicly viewable, no login, explaining what the app does. A privacy policy on that same domain, linked from the consent screen, describing how you access, use, store and share the provider’s user data. Brand verification has to be approved and published before you can request data-access verification — these are sequential, not parallel.

The consistency requirement is stricter than people expect. Same app name and description across product, consent screen, homepage and privacy policy. Any mismatch is a reason for the reviewer to stop and email you, which costs a round-trip.

Record a walkthrough video

Required for sensitive and restricted scopes. Show each permission connected to the feature on screen that uses it. The reviewer should never have to infer why you need something.

Stay reachable

Google follows up by email to project owners and editors. Keep the support email and developer contact current and actually watch those inboxes. If your feature sits behind your own login, Google may ask for a test path in — a login URL, instructions to reach the connection, an allowlisted reviewer email, sample data. Walk that path yourself before sending it.

After you’re approved, it isn’t over

Four things to put in your calendar rather than discover:

• New scope = new review. Test it in a separate project.
• Branding changes can trigger re-review — name, logo, homepage, authorized domains. Google also locks branding edits while a verification is running, so don’t start a rebrand mid-review.
• Rotate the OAuth client secret periodically, in both Cloud Console and your builder’s connection settings. Don’t let it sit for years.
• Users can revoke access at any time. Your app needs to notice the broken connection and prompt a reconnect, not fail silently at 3am.

And if you’re on restricted scopes: CASA repeats annually, forever, as long as you want that access.

The honest read

This is a good problem to have. Two years ago, an app that connects to each user’s own account was out of reach for a solo non-technical founder — not because of the review, but because of the plumbing. That’s genuinely solved now.

What replaced it is a process problem, and process problems reward planning. Decide what the product does, ask for the least access that makes it work, make every surface tell the same story, and put four to six weeks in the launch plan instead of four days.

The same logic carries to Slack, HubSpot, and everyone else with a review queue. Google is just the one with the best-documented gauntlet.

Two related reads: what Lovable’s trust centers do and don’t prove when a buyer runs a security review on you, and the authorization gap if your app does things on a user’s behalf while they’re not watching.