Matthew Canaday built SkyRingAI, an AI phone receptionist for home service businesses. It answers the call, qualifies the caller, and books the job straight onto the owner's Google Calendar. To book the right time, it works with each user's real availability in Google Calendar.
Building a product that connects to each user's Google data used to be extremely cumbersome for a solo builder like Matthew. It meant building authentication, storing credentials safely, routing every request through the right user permissions, and maintaining the security model around it.
With app user connectors, Lovable now handles the technical foundation. Each person connects their own account. Credentials stay in Lovable's connector gateway, and the app acts with that person's existing permissions.
Beyond the technical side, building an app that works with users' third-party data puts added responsibility on the builder.
Providers—such as Google, HubSpot, Slack—often require apps to be reviewed before they can connect to user data. We spoke with Matthew to help break down Google's process for others. In this article, we'll explain how to navigate building with third-party user data, using Matthew's experience with Google as the example.
The shared responsibility behind third-party user data
When a Lovable app works with a user's Google Calendar data (or any third-party data), responsibility for that data is shared across three parties.
Lovable handles the technical connection. Credentials are stored server-side and encrypted. The generated app never receives the credential itself. Requests pass through Lovable's connector gateway, and each user's existing permissions in the source system still determine what data they can access.
That technical foundation has to be upheld even when users are not actively in the app. For example, SkyRingAI's receptionist books the calendar owner's schedule at 9pm, while the owner's nowhere near the app. Managing that safely, without the owner in the loop for every request, is called offline access. Under the hood, Lovable keeps the connection live and secure even when the user is offline, enabling apps to keep acting on their behalf once they've left a session.
For deeper security details, see how Lovable secures connected data in production apps.
You decide what data is accessed and how it is used. Each scope of data requested from a third-party source must support a visible user-facing feature, and users should be able to understand why the app needs it. Lovable protects the provider credential and enforces the user identity used for gateway calls. However, if the app stores, logs, shares, or otherwise processes the returned Google data, the builder remains responsible for access control, retention, deletion, and disclosure. The person building the app is accountable for ensuring alignment between: the permissions the app requests, users' understanding of their data use, and the product's functionality.
The third-party provider (e.g. Google, Slack, HubSpot) decides which apps can access its users' data. Google and other providers define the permissions an app can request. They use review processes to evaluate how an app handles user data before granting public access.
Determining whether your app needs review
Not every app that connects to Google needs review. You can build and test an external app with a limited set of test users before submitting for review. Apps used within a single Google Workspace organization can be configured as internal and do not need to be reviewed.
The review process depends on the permissions the app requires. Google calls these permissions scopes. A scope defines what an app can do with a user's Google data, such as view calendar availability, read event details, create files, or send email.
When you add scopes on the Data Access page in Google Cloud Console, Google labels each one as non-sensitive, sensitive, or restricted.
- Non-sensitive scopes, such as basic sign-in access to a user's name, email address, and profile, do not require data-access verification. You may still need brand verification if you want your app's name and logo to appear on the consent screen.
- Sensitive scopes expose private user data or allow the app to act on it. Reading Google Calendar events is one example. Google reviews why the product needs that access and where the functionality appears in the app.
- Restricted scopes provide wide access to Google user data.
gmail.readonlycan view a user's email messages and settings.drive.readonlycan view and download all of a user's Drive files. Unlike sensitive scopes, restricted scopes add a separate security assessment through the CASA framework, which you must repeat every year. That difference affects both your launch timeline and your ongoing responsibilities.
So, adding Drive and Gmail access upfront 'in case you need them later' is not just one more checkbox; it can move your app into a tier with a recurring paid audit attached. Restricted scopes add annual security reassessment and may introduce third-party assessment costs. In the case of SkyRingAI, Matthew asked for admin permissions to the calendar (read, write, cancel, schedule) and nothing else.
The level of permissions your app needs determines how thorough the review will be. The label Google shows when you add the scope determines which requirements apply. Google's OAuth verification help center explains the review paths and exceptions.
The Google OAuth verification process
Matthew's advice was simple: decide exactly what the app needs before you ask Google for access.
The steps below follow Google's process. The same principle works across providers: connect access to a visible user need, request the minimum permissions that feature needs, and make the finished app easy to review.
1. Define the user-facing feature first
Before you open Google Cloud Console, get specific about what the user should be able to do and which Google data makes that possible.
For SkyRingAI, the relevant job was scheduling. The app needed to check availability and book an appointment.
Write down:
- What the user can do
- Which Google product provides the data
- Whether the app reads, creates, updates, or deletes anything
- Why a narrower permission would stop the feature from working
You'll use this list to choose scopes, write the privacy disclosures, record the walkthrough, and answer Google's review questions.
2. Map each feature to the minimum scopes it needs
Minimum permissions is best practice for every connection: ask only for the access the current feature needs. It protects users, and Google will hold you to it during review. For example, SkyRingAI needs full calendar-level access because the receptionist works across whichever calendars a business books on, not a single known calendar.
Once you have the feature list, map each one to the narrowest Google scope that supports it. For Google Calendar, if your app only needs to see whether someone is free, calendar.freebusy may be enough. However, if you need to create or edit events, calendar.events may be a more fitting scope.
Google's Calendar authorization guide lists the full set of scopes and what each one allows.
For every sensitive or restricted scope, be ready to explain:
- What the permission allows
- Where the user sees that functionality
- Why the feature cannot work with a narrower scope
Google reviews whether requested access exceeds the functionality already present in the app.
3. Build the app and test the Google connection
At this stage, build the visible feature and configure Google OAuth in a test setup. At a high level, you'll want to ensure the app has the right APIs, scopes, and OAuth consent screen. Next, create a Web application OAuth client with Lovable's redirect URI and plug the client ID/secret into Lovable's connection settings. By the end, a test user should be able to sign in, grant access, and use the feature from start to finish.
For the exact steps, follow Google's step-by-step authentication and authorization guide.
It's important that the app works end-to-end before you submit it. Reviewers need to see the same product, branding, consent screen, scopes, and functionality named in the application.
4. Prepare your customer-facing assets
Before you submit, publish a homepage on a domain you own. Anyone should be able to view it without logging in, and it should explain what the app does.
Branding has to be verified and published before you can request data access verification. Google's brand verification requirements detail exactly how to ensure your app accurately represents its identity and intent to all users.
For example, using the same app name and description across the product, consent screen, homepage, and privacy policy. You also need a privacy policy hosted on that same domain, linked from your consent screen, explaining how the app accesses, uses, stores, and shares Google user data. Consistency is key so the reviewer has no reason to stop.
5. Record a walkthrough of the app working
Google requires a demonstration video when you submit an app that uses sensitive or restricted scopes. For the complete guide on what the walkthrough demo needs to show, Step 2 of the Sensitive and Restricted Scope Requirements section of the verification requirements goes over this in detail.
Connect each permission to the feature that uses it on screen. The reviewer should not have to infer why the app needs access.
6. Submit from Google Cloud Console and stay reachable
Once the production app, branding, scopes, and supporting materials are ready, follow Google's submission process. Open Audience in Google Auth Platform. Change the publishing status from Testing to In production by selecting Publish app. Then select Prepare for verification and complete the Submit for verification flow.
Google handles follow-up over email with the project owners and editors. Keep those contacts, the support email, and the developer contact information current. Monitor those inboxes while the review is open.
There is no single reliable review timeline. Brand checks may move quickly, while Google publishes an estimate of up to 10 days for sensitive scope review. Restricted scopes run longer because of the security assessment. Build that uncertainty into the launch plan instead of treating the review as a final-day task.
7. Be ready to give Google a working path into the app
The demo video is part of the initial submission for sensitive or restricted scopes. Login access is different.
If the feature sits behind your app's own login, Google may later ask for a way to test it. If that happens, reply to the OAuth verification email with:
- The login URL
- Instructions for reaching the Google connection
- An allowlisted reviewer email or a test account, if needed
- Any sample data or inputs required to exercise the feature
Google's in-app testing guide explains the access options. Test the path yourself before you send it. A reviewer who cannot reach the feature cannot verify it.
8. Keep the access current after you're approved
Verification isn't a one-time gate. A few things to plan for once your app is live:
- Scope changes. Adding a new scope later puts you back in review before users can grant it. Test it in a separate project.
- Branding changes. Branding changes can trigger re-review. App name, logo, homepage, or authorized domains. Google also locks branding edits while a verification is running.
- Secret rotation. Rotate your OAuth client secret periodically, both in Google Cloud Console and in Lovable's connection settings. Don't let it sit unchanged for years.
- Revocation. Users can revoke access from their Google account at any time. When that happens, your app should recognize the broken connection and prompt the user to reconnect.
- Annual reassessment. If your app uses restricted scopes, the CASA security assessment repeats every year. Google emails the project owners and editors, so keep those contacts current.
Start building
Getting verified can feel daunting, especially the first time. But the review comes back to a few fundamentals.
Start with the job your app needs to do. Choose the minimum scopes required to make that feature work. Then make sure your product, consent screen, privacy policy, and walkthrough all tell the same story about the data you access and why.
You don't need to be a large company to meet that bar. What matters is clarity of thought: ask only for what the product needs, explain how you'll use the data, and make sure the product does exactly what you said it would.
As stated, this is just one process for one provider. For the complete list of providers and guides, follow the Lovable guide to letting app users connect their own accounts.
