✅ When You Create a Credential for Google Calendar API…
You are creating credentials (OAuth 2.0 client) that authorize your application (mywebsite.com) to access Google Calendar data on behalf of a user.
➡️ The data types accessed depend on how your app interacts with Google Calendar through OAuth 2.0.
✅ Data Types Explained
| Data Type | Explanation |
|---|---|
| User Data | ✅ YES, you are accessing user data—specifically the user’s Google Calendar events, including event titles, descriptions, attendees, and times (depending on scopes). |
| Application Data | ❌ NO, not unless you have your own calendar app that stores data inside your app or your own database independent of Google’s services. |
➡️ OAuth 2.0 credentials you create are primarily for accessing user data in their Google Calendar.
✅ What Happens in Your Scenario: mywebsite.com
- You create OAuth 2.0 client credentials.
- Users (like Jack) log in and authorize mywebsite.com to access their Google Calendar data.
- With proper scopes, your app reads/writes user calendar data (events, attendees, etc.).
- This access is limited by OAuth 2.0 scopes, meaning you only access what you explicitly request.
➡️ So, you are accessing User Data, not just application data.
✅ How to Define the Data You Access: The Role of OAuth 2.0 Scopes
When you define OAuth 2.0 scopes, you're telling Google what level of user data you want to access.
Example Scopes:
| Scope | What You Can Access |
|---|---|
https://www.googleapis.com/auth/calendar.readonly |
Read user calendar events only |
https://www.googleapis.com/auth/calendar.events |
Read/write/create/delete user events |
https://www.googleapis.com/auth/calendar |
Full access to all user calendar settings and events |
➡️ Google displays these scopes in the OAuth Consent Screen, informing the user what personal data you’re requesting access to.
✅ When It’s Just Application Data
- If you’re not using OAuth 2.0, but using API keys for public data (like a public calendar embed) ➜ You may only be interacting with application data.
- But in most cases with Google Calendar API, it's user data, because:
- You’re accessing personalized user calendars.
- You need user consent to read/write their calendar data.
✅ Examples to Clarify
➤ Example 1: User Data
Jack logs into mywebsite.com, authorizes the site, and gives you access to his calendar ➜ You are accessing user data.
➤ Example 2: Application Data
You use the API to manage a company calendar owned by mywebsite.com, and only admins interact with it ➜ You’re managing application data, but under the hood, it’s still Google Calendar API user data.
✅ In Google Cloud Console: OAuth 2.0 Consent
When you set up OAuth 2.0 in Google Cloud Console:
- You specify what type of data your app accesses (Google asks this during OAuth consent setup).
- Since you’re using Google Calendar API, the answer is User Data, because:
- You’re requesting access to an individual’s calendar.
- You need OAuth consent to access, create, or edit their data.
✅ TL;DR
- ➤ You are accessing User Data, because Google Calendar contains personal event data.
- ➤ Application Data would apply if you were managing your own data (e.g., on your own server).
- ➤ Google Calendar API requires user consent, so you're explicitly working with User Data, even if it's for internal company use on mywebsite.com.
✅ Next Steps
When creating the OAuth consent screen for mywebsite.com, make sure to:
- Choose User Data.
- Explain why you're accessing calendar data (Google requires this for approval, especially if you use sensitive scopes).