What "Google hasn't verified this app" and "Access blocked" mean for a calendar app

Three screens, three causes

People who sign in to a calendar app that Google has not verified can land on one of three Google screens. They look alike and are often lumped together, but each has a different cause and a different fix.

All three come from the same starting point. Google classes calendar access as sensitive, and an app that requests it has to pass Google's OAuth verification before these screens go away.

"Google hasn't verified this app"

Google's definition: "An unverified app is an app or Apps Script that requests a sensitive or restricted OAuth scope." Such an app "might display an 'unverified app' screen before it displays the consent screen". Google lists three triggers:

• The app asks for sensitive or restricted scopes and has not been configured for verification.
• The scopes requested in code differ from the scopes on the consent screen configuration.
• Verification was submitted and is still pending.

The second trigger catches verified apps too. If you add calendar.events to the code after Google approved calendar.readonly, users see the warning again until the new scope is reviewed.

What users can do

Users can still get through. Developer reports describe an "Advanced" link on the warning that reveals a "Go to (unsafe)" link, which leads to the normal consent screen. Google's help pages don't describe that path, so treat it as observed behavior.

Few people click a link labeled unsafe, and Google also limits how many can. Unverified apps get "100 new users in total, after the app presents the unverified app screen". Google's FAQ says the cap "applies over the entire lifetime of the project, and it cannot be reset or changed", and exhausting it can "cause Google sign-in to be disabled" for the app.

Test users see a version of this screen too. In Testing, "Google will display a warning message before allowing a specified test user to authorize scopes".

What developers do

Submit the app for verification. Calendar scopes are sensitive, not restricted, so the review needs verified domains, a privacy policy, scope justifications and a demo video, but no security assessment. Google's FAQ estimates 10 business days for sensitive scopes and adds that "these estimates are not guaranteed". How long the review takes in practice is covered separately.

While you wait, make sure the scopes in your code match the consent screen exactly, and spend the 100-user cap on people who matter, since it never comes back.

"Access blocked" and Error 403: access_denied

The full message reads "Access blocked: has not completed the Google verification process", with "Error 403: access_denied" in the details. It is one of the most viewed Google OAuth questions on Stack Overflow.

Google does not document this screen. In every report we found, the app's publishing status was Testing and the account signing in was not on the test user list. Google's description of Testing fits: projects in Testing "are limited to up to 100 test users", while projects In production "are available to any user with a Google Account".

What users can do

Nothing on their side. The user has to ask the developer to add their account, or wait for the app to move to production.

What developers do

Pick one:

1. Add the account as a test user. In the Google Cloud console, open the OAuth consent screen settings, go to Audience, and add the address under Test users. The top Stack Overflow answer gives this fix. You get up to 100 test users, and their authorizations "will expire seven days from the time of consent", refresh tokens included. See why refresh tokens expire after 7 days.
2. Publish the app to In production. Anyone with a Google Account can then sign in. Until verification passes they see the unverified app warning above, and the 100-user cap applies.

A related "Access blocked": org_internal

An app set to the Internal user type only accepts accounts in its own organization. Anyone else gets the org_internal error, which Google returns when the OAuth client belongs to "a project limiting access to Google Accounts" in one Google Cloud Organization. The fix is to switch the user type to External, which brings back the verification requirement.

"This app is blocked"

The full text reads "This app is blocked. This app tried to access sensitive info in your Google Account. To keep your account safe, Google blocked this access." There is no Google help page for it, and no documented fix. Developer threads, such as this one on Stack Overflow, tie it to specific accounts rather than to the app as a whole: accounts in organizations with app restrictions, or accounts with extra protections turned on. The same app often works for other accounts.

If only some users see it, ask whether they use a Google Workspace account and whether their administrator manages third-party app access. If the account is a personal one with no administrator, there is no confirmed fix to offer.

When a Workspace administrator blocks the app

Workspace administrators control which third-party apps can reach their users' data, under Security, Access and data control, API controls. Each app can be set to Trusted, Specific Google data, Limited or Blocked, and an administrator can mark the Calendar service as Restricted. With Calendar restricted, "only internal and third-party apps configured with a Trusted or Specific Google data access setting can access data".

A user who tries to sign in to a blocked app is, in Google's words, "notified that the app is blocked". Your app receives the admin_policy_enforced error, which Google describes as "The Google Account is unable to authorize one or more scopes requested due to the policies" set by its Workspace administrator.

Verification doesn't change this. Only the customer's administrator can, by trusting the app. Since August 2025, users blocked from an app the administrator has not configured see "an error screen with an option to raise a review request to admins", so a request may already be waiting in the administrator's Apps pending review list.

How Pyas handles it

With Pyas Auth, your users approve Pyas on Google's own consent screen. Google has already verified Pyas, so users don't see the unverified app warning, there is no test user list or 100-user cap, and you don't go through Google's OAuth review. This is the same on every plan, the free one included.

If you switch Google to Native Auth, your own OAuth client is used and everything on this page applies to your app. A Workspace administrator can still block calendar access for their organization either way. When an account stops working, GET /v2/accounts/{accountId}/status says why, and the connection.broken webhook tells you when it happens.

Common questions

Do test users see the unverified app warning?

Yes. Google shows test users a warning before they authorize sensitive scopes, so they know the app is unverified.

Can I get more than 100 users without verification?

No. The cap covers the project's whole lifetime and Google says it "cannot be reset or changed". Verification is what lifts it.

Does an app used only inside my own Workspace organization show these screens?

An app with the Internal user type, used only by accounts in your own organization, doesn't need verification. Accounts outside the organization get the org_internal error instead.

Is "Access blocked" the same as access_denied in my redirect?

The screen shows "Error 403: access_denied". Your redirect URI receives error=access_denied when the user does not approve the request, so the same code can mean a declined consent or a blocked account. Check the publishing status and test user list first.

Why do some users see "This app is blocked" when others sign in fine?

Reports point to the account, not the app: a Workspace policy, or extra protections on that account. Google has not documented the screen, so ask the user about their account type and administrator.