Justify the Google Calendar scope for OAuth verification
Calendar is a sensitive scope, so Google wants a concrete justification tied to a feature a user can see — and an answer to 'why not a narrower scope?'
Vague justifications ('we need calendar access to work') get rejected. Google asks for one justification per sensitive scope, each mapped to a specific user-facing feature, and — because narrower Calendar scopes exist — either that you use the narrowest one that works or a clear reason a broader one is required. Over-asking without a justification is itself a ground for rejection.
Each fix below traces to a requirement Google publishes.
Nothing here is our opinion. Every requirement links to Google’s own page — open it and verify the fix yourself before you resubmit.
“Every requested scope is classified non-sensitive, sensitive, or restricted — the category is shown per scope in the Cloud Console, and it decides your verification path.”
“Give one justification per sensitive scope, each tied to a specific feature a user can see.”
“Where a narrower scope exists, either switch to it or explain why it won't do — over-asking without a justification is itself a rejection ground.”
“Declare every scope your code actually requests — an undeclared runtime scope is a rejection.”
Do these in order.
- 01
Tie the scope to one visible feature
Name the exact feature: e.g. 'read the user's events to show free/busy times in our scheduling view' or 'create events when the user books a slot'. One feature, one justification.
- 02
Use the narrowest Calendar scope that works
If you only display events, calendar.readonly beats full calendar. If you only manage events your app creates, calendar.events is narrower than full calendar. Request the least access the feature needs.
- 03
If you need broad access, say why the narrower one fails
Explain concretely what the narrower scope can't do for your feature. 'We need to modify events the user created elsewhere, which calendar.events.readonly can't do' is the shape Google wants.
- 04
Declare exactly what you request
Make sure the Calendar scope your code requests is the one declared on the consent screen — no undeclared runtime scopes.
What each scope actually grants.
The tier decides your path: non-sensitive needs only brand verification, sensitive needs a justification and demo video, and restricted needs a separate security assessment. Google’s scope categories →
| Scope | Tier | What it accesses |
|---|---|---|
| calendar | Sensitive | Calendar events (read/write) |
| calendar.events | Sensitive | Calendar events (read/write) |
| calendar.readonly | Sensitive | Calendar events (read) |
| calendar.events.readonly | Sensitive | Calendar events (read) |
Narrower alternatives exist (Google prefers the least access that works): calendar → calendar.events → calendar.events.readonly; calendar.events → calendar.events.readonly; calendar.readonly → calendar.events.readonly.
See exactly what Google’s crawler sees — free.
Paste your URL and scopes. The pre-check fetches your homepage the way Google does, finds your privacy-policy link, and flags the blockers this rejection is about — in seconds, no signup.
Straight answers.
Do I need a demo video for the Calendar scope?
Sensitive scopes generally require a demo video that shows the scope in use. Demonstrate the Calendar feature on screen as part of the grant-flow video.
Which Calendar scope should I request?
The narrowest that supports your feature — calendar.readonly to display events, calendar.events to manage events you create, and only full calendar if you can justify why the narrower ones won't do.