Justify the Google Contacts scope for OAuth verification
Requesting Contacts means proving a specific feature needs it — and defaulting to read-only unless your app genuinely writes to the user's contacts.
Contacts access is sensitive because it exposes other people's personal data. Google wants the justification pinned to a visible feature (a CRM autocomplete, an invite picker) and expects contacts.readonly unless you actually create or edit contacts. Asking for read/write when you only read is over-asking, which is rejectable on its own.
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.”
“Your privacy policy must disclose how the app accesses, uses, stores, and shares Google user data specifically — named per scope.”
Do these in order.
- 01
Name the feature that reads contacts
For example: 'suggest recipients from the user's contacts when they compose an invite'. Map the scope to that one feature.
- 02
Default to contacts.readonly
If you never create or modify a contact, request contacts.readonly rather than the read/write contacts scope. Reserve read/write for a real write feature.
- 03
Disclose contacts data in your policy
State in your privacy policy what contact data you read and how you use, store, and share it — this is third-party personal data, so be specific.
- 04
Justify any broader access
If you request read/write, name the write feature and explain why read-only can't deliver it.
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 |
|---|---|---|
| contacts.readonly | Sensitive | Contacts (read) |
| contacts | Sensitive | Contacts (read/write) |
| contacts.other.readonly | Sensitive | Other contacts (read) |
Narrower alternatives exist (Google prefers the least access that works): contacts → contacts.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.
Should I request read-only or read/write for Contacts?
Read-only (contacts.readonly) unless your app actually creates or edits contacts. Requesting read/write when you only read is over-asking and can be rejected.
Does my privacy policy need to mention contacts?
Yes. Because contacts are other people's personal data, disclose specifically what you read and how you use, store, and share it.