Hi @Benjamin2
The error you are seeing (“The attempted action failed, please try again”) is actually coming from Google’s own Cloud Console, not from n8n. It is a generic message indicating that Google’s system encountered a glitch while trying to save your OAuth client settings. This usually happens because of a conflict in your browser rather than a mistake in your n8n configuration.
The most common cause is being logged into multiple Google accounts in the same browser session, which often confuses the Google Cloud Console. To fix this, the fastest solution is to open an Incognito or Private window and log into only the specific Google account you are using for this setup. If that doesn’t work, try disabling browser extensions (like ad-blockers) or clearing your browser’s cache and cookies.
Finally, double-check that you have selected “Web application” as the application type. When pasting your Redirect URI from n8n, ensure there are no accidental spaces at the beginning or end of the link. Since you are self-hosting via Hostinger, also verify that your n8n environment variable WEBHOOK_URL is correctly set and includes the https:// prefix, as a missing protocol can cause Google to reject the request.
Thanks so much @kjooleng for the tips. I tried everything you said
but I still get the same error notification.
Since the browser changes did not move it, I’d stop treating this like an n8n issue for the moment and test the Google project itself. If the same Google account or project cannot create any OAuth client, the problem is likely on the Google side rather than in n8n. Can you confirm whether this is a brand new project or one reused from an older setup?
@OMGItsDerek thanks so much for your reply.. it’s a brand new project. I’m actually trying to set this up for a colleague who’s working in the same organisation than me. I double checked:: I got no problems when i add another client in my google console. With her I always get the same error notification. any tips how to solve this?
Hi @Benjamin2
Based on your new info, this is what may have happened
The error you are seeing is a generic “catch-all” message, which means Google knows something is wrong but isn’t telling you exactly what. Since you can create clients for yourself but not for your colleague’s new account, the problem isn’t the process itself, but likely a missing setting or a restriction tied to that specific new account.
The most common culprit is the “OAuth Consent Screen.” Think of this as the digital “welcome mat” that users see when they log in. Every single new project requires its own consent screen to be fully configured. If any required field is empty or wasn’t “Saved and Continued” through to the very end, Google will block you from creating the Client ID.
You should also check the account permissions. Even if your colleague is part of your organization, she might not have the “Editor” or “Owner” role for this specific project. If she has “Viewer” or limited access, the console might let her open the creation page, but it will trigger an error the moment she tries to actually save the new ID.
Because this is a brand new Gmail account, Google might be applying a temporary security “cooldown.” To prevent spam, Google sometimes restricts new accounts from creating security credentials for a few days. Additionally, make sure the app is set to “Internal” (for your company only) rather than “External,” as external apps require a much stricter verification process.
Don’t overlook simple browser glitches. The Google Cloud Console is very complex and often gets confused by old cookies or cached data from other accounts. A simple switch to an “Incognito” or “Private” window, or trying a completely different browser, often clears up these “phantom” errors that don’t have a clear technical cause.
To solve this quickly, start by trying an Incognito window. If that doesn’t work, go back to the “OAuth Consent Screen” and make sure every page is filled out and saved. Finally, verify that your colleague is listed as an “Editor” in the project’s IAM settings. If all those fail, wait 24 to 48 hours for the new account to be fully trusted by the system.
This usually happens when the webhook URL or n8n public URL is wrong or not set correctly, so the OAuth redirect URL gets generated incorrectly.
This happens on new accounts when the OAuth consent screen isn’t set up first. Before creating the client ID:
Go to APIs & Services > OAuth consent screen and complete that setup
Then go to APIs & Services > Library and enable the specific API you need (Gmail API, Google Drive, etc.)
Then create the credentials
If you already did those steps, try in an incognito window; Google Cloud Console sometimes caches a bad state that blocks credential creation.
Go to your OAuth Consent Screen settings in the Google Cloud Console. Look at the User Type. If it is set to Internal, it will instantly reject anyone who doesn’t have the exact same email domain name as you. Change the User Type to External, save it, and then try adding them.
Let me know if this works, or if you both have the same email.
I am having the same issue, I am use my callback URL is true but I do now how to overcome with this useless problem. I have connected 3 g-mail auth to one account, can it be the reason google blocking me? Should ı host new n8n instance or what?
Thanks so much @SE-automations but I had already put it on external. i get the same error
@Oguzhan_Murat this would also be my 3rd account to connect. I never had problems before but with that one I do. Not sure if that is really the issue though
@Asim_Arman thanks so much. I enabled all the APIs I needed before. unfortunately it didn’t make the difference. Incognito mode didn’t help either. so weird!
Hey I’m super new to all of this but had the exact same issues during setup where I got an error — here’s my solution that I figured out with AI, hope it helps! 
Google no longer allows Hostinger’s standard domain as a top-level domain in the branding section. You must use your own custom domain there.
The solution is simple: Use your own domain, create a subdomain via a CNAME record (e.g. with api. in front), and enter this in the Hostinger panel via the .yaml editor. This removes the Hostinger domain and everything works perfectly.
For guidance on the rest of the Google integration, this video helps:
Here’s a quick summary of the steps:
1. Create a CNAME record at your domain provider
Your main website remains unchanged. You simply create a subdomain with your own domain provider:
Type: CNAME
Hostname/Name: api (or another abbreviation)
Target/Value: The full Hostinger address with a period at the end (e.g. n8n.srvXXXXX.hstgr.cloud.).
Important: Leave the “Subdomain?” option disabled and don’t forget the period at the end of the URL!
2. Adjustment in Hostinger hPanel
To make n8n use the new address, adjust the Docker project in Hostinger:
In the VPS menu, go to Docker Manager → Projects and manage the n8n project.
In the Environment section at the bottom, change the variables:
DOMAIN_NAME = your-domain.com (Your main domain without www or https)
SUBDOMAIN = api (The CNAME abbreviation you chose)
Click Save and Deploy. Hostinger restarts n8n and generates the SSL certificate.
3. Finalize Google Cloud Console
OAuth Consent Screen: Under Authorized Domains, enter your own main domain (e.g. your-domain.com). Google now accepts this top-level domain immediately.
Credentials: In the OAuth Client ID under Authorized Redirect URIs, enter the n8n callback URL with the new domain: https://your-domain.com
I am sorry it didn’t work, maybe this fix will work:
In Google Cloud, go to the OAuth consent screen tab. Under User Type, if you are using a standard @gmail.com account, you must leave it as External but look for the Publishing status section. Ensure it is set to Testing mode (do not click Publish App). Finallyally, you must explicitly add your new Gmail address to the Test users list right below it. If your email isn’t on the test list, Google will block the connection.
Let me know if this works.
Welcome to the n8n community @Benjamin2
Since it works on your account but fails on your colleague’s account, I would check Google Workspace permissions/restrictions or create the OAuth Client in the project using an account with Owner/Editor role. Just copy the OAuth Redirect URL from the Google credential and paste it in Authorized redirect URIs.
If the error persists, please share your JSON without sensitive data so we can better understand the issue.
I have the same problem. A Google Calendar credential that worked until about a week ago, suddenly stopped working.
My Google Cloud Console app doesn’t accept Hostinger URLs anymore.
Hey all,
Thanks so much for your replies. In the end, I managed to solve it.
Unfortunately, I can’t say for sure what exactly fixed the issue. My best guess is that there was something wrong with the configuration of the Google Cloud project I had created.
I didn’t change anything in Hostinger, the domain settings, or anything similar to make it work. I simply tried again and used the initial default project, “My First Project,” without renaming it.
Suddenly, everything worked.
Thanks again for your help!
@albertocv for the Hostinger URL issue - Google started enforcing stricter domain validation for OAuth authorized origins. The common fix: make sure the Authorized JavaScript origins entry exactly matches your Hostinger domain including the protocol (e.g. https://yourapp.hostinger.com with no trailing slash), and add your n8n instance’s callback URL to Authorized redirect URIs in the format https://yourapp.hostinger.com/rest/oauth2-credential/callback. If you’re on a Hostinger subdomain, also try adding the root domain as an authorized domain in the OAuth consent screen.
