N8n Cloud: Catch-22 with Google Calendar OAuth and AI Agent (Cannot input Client ID/Secret)

Hi everyone,

I am running into a frustrating roadblock on n8n Cloud while trying to build an AI Agent (connected to an ElevenLabs voice agent) that checks availability and creates events in a specific Google Calendar.

I seem to be stuck in a Catch-22 regarding authentication, and I’m hoping someone here has a workaround.

The Goal

I have a workflow with an AI Agent node connected to Google Calendar tool nodes (“Get many events” and “Create an event”). The agent needs to read free/busy slots and book appointments into a specific calendar.

The Problem & What We’ve Tried

Attempt 1: Using the Default Managed OAuth (Sign in with Google) I used the standard “Google Calendar account” credential in n8n Cloud. I clicked “Sign in with Google”, and it connected successfully (showing the green “Account connected” status).

  • The Issue: Even though it says connected, the AI Agent consistently fails to actually read from or write to the calendar. It seems like a scope or permission issue, as the agent simply cannot access the data despite the green connection status.

Attempt 2: Creating a Custom App in Google Cloud Console Following several tutorials to fix these permission/scope issues, I went into the Google Cloud Console, created a dedicated project, enabled the Calendar API, configured the OAuth consent screen, and generated my own Client ID and Client Secret.

  • The Blocker: Because I am on n8n Cloud (not self-hosted), the native “Google Calendar account” credential setup completely hides the Client ID and Client Secret fields. It forces me to use n8n’s managed OAuth. There is no toggle or option to input my custom GCP credentials for the native Calendar node.

Attempt 3: Using the Generic Google OAuth2 Credential To bypass this, I tried creating a generic “Google OAuth2 API” credential. This setup does allow me to input my custom Client ID and Client Secret.

  • The Blocker: The native Google Calendar tool nodes connected to my AI Agent refuse to accept this generic credential type. They strictly require the specific “Google Calendar account” credential type.

My Questions

  1. How can I force the native Google Calendar credential node on n8n Cloud to accept a custom Client ID and Client Secret? Is there a hidden setting to disable the managed OAuth?

  2. If custom OAuth is strictly impossible on n8n Cloud for these native nodes, why is the AI agent failing to read/create events when using the managed “Sign in with Google” setup, even when it shows as connected? (The calendar is properly shared with edit rights to the authenticated account).

It feels like the UI is preventing me from using the proper technical setup, while the “simple” managed setup doesn’t give the AI agent the actual access it needs.

Any guidance would be hugely appreciated!

PS: if there is something EASY because at this stage I do not understand why N8N has created a Node Google Calendar “Create Event” if it can’t work with just logging in with a Google Calendar basic login.

Are you on the starter plan, @JCBuildsAI ? If so, you are using shared n8n credentials.

You need Pro plan in order to use your own custom OAuth credentials

Welcome @JCBuildsAI to our community! I’m Jay and I am a n8n verified creator.

The managed “Sign in with Google” credential on n8n Cloud uses scopes that cover basic Calendar access, but the AI Agent tool nodes may need specific scopes like https://www.googleapis.com/auth/calendar.events to actually write events. When connected but failing, that’s usually the culprit. The workaround is to disconnect and reconnect the Google Calendar credential, but this time check which scopes are being requested during the OAuth consent screen - if calendar write scope isn’t in the list, you’ll need to create a new Google Cloud project with a custom OAuth app, set the required scopes manually, then use the “Google Calendar OAuth2 API” credential type in n8n (not the standard “Google Calendar account”) which does expose Client ID/Secret fields even on Cloud.

@JCBuildsAI , please mark it as solution if it does help you.

Hi Jai thx for the shoot, I tried to explain in my email here where i am stuck: Video link

After creating the google cloud project, you can’t create a google calendar OAuth2 API with credentials like you mention, neither in standar or pro plan

See the screenshot there is nothing you can do here - any take after checking my video?

hi i just posted this video your proposal to move to pro plan or standard does not change anything - see the video: Link Video - please could you check it and give me your opinion?

So far I spotted one anomaly, there could be more

Seems like your redirect URI is wrong

You may refer to below link for more info

Just found this thread which may help

In Google Cloud Console, you don’t create a “Google Calendar OAuth2 API” - that’s not a thing there. What you need is: go to APIs & Services > Credentials > Create Credentials > OAuth Client ID, choose Web Application as the type, then set the redirect URI to the one n8n gives you in the credential setup screen. That gives you the Client ID and Client Secret to paste into n8n’s “Google Calendar OAuth2 API” credential. Make sure Google Calendar API is enabled under APIs & Services > Enabled APIs first. If you’re seeing the credentials page without an option to create OAuth Client ID, check that you’ve completed the OAuth consent screen setup under APIs & Services > OAuth consent screen.

Thank you as you can see on this video he uses a self hosted N8N and not the hosted N8N solution which does not have the fields available. So basically I believe its not working on hosted N8N

@JCBuildsAI, good morning!

what works for me is using a generic Google OAuth2 credential with an HTTP Request/HTTP Request Tool calling the Calendar API directly.

@JCBuildsAI it does work on n8n Cloud - the “Google Calendar OAuth2 API” credential type in n8n has fields for Client ID and Client Secret on both Cloud and self-hosted. What you need to do is create the OAuth Client ID in Google Cloud Console (not inside n8n), then paste those values into n8n’s credential. The steps I described earlier apply exactly the same on Cloud. Can you share a screenshot of what you see when you open the “Google Calendar OAuth2 API” credential in n8n? That would help confirm where the confusion is.

@JCBuildsAI the method @nguyenthieutoan suggested will definitely work. i have created something similar also but on the self hosted version. You just have to create the OAuth2 API credential on google console not on n8n and it should work.

Hey JCBuildsAI,

I’ve hit this exact pattern before. The managed OAuth on n8n Cloud should work — the issue is almost always one of these two things:

Most likely: scope mismatch during the OAuth consent flow.

When you clicked “Sign in with Google,” the consent screen may not have requested all the Calendar scopes the AI Agent needs. Try this:

  1. Go to your Google Account → Security → Third-party apps with account access
  2. Find the n8n connection and remove it entirely
  3. Back in n8n, delete the existing Google Calendar credential
  4. Create a new one and sign in again — this time watch the consent screen carefully and make sure you grant all requested permissions (read, write, manage calendars)

The re-auth forces Google to re-prompt for scopes instead of silently reusing a stale grant.

If that doesn’t fix it: calendar ownership mismatch.

The OAuth authenticates as your Google account, but the AI Agent may be trying to access a calendar that’s shared with you rather than owned by you. Check which specific calendar ID the tool nodes are targeting — if it’s a shared calendar, you need explicit “Make changes to events” permission, not just “See all event details.”

Workaround for Attempt 3 (generic OAuth + AI Agent):

You’re right that native Calendar nodes reject the generic credential. But you can build the same
functionality using HTTP Request nodes with your generic Google OAuth2 credential, calling the
Calendar API directly:

Wire those HTTP Request nodes as tools into your AI Agent — the Agent doesn’t care whether the tool is a native node or an HTTP Request, it just sees the input/output schema.

This approach also gives you full control over error handling and retry logic, which you’ll want
anyway once this is handling real bookings.