Google Service Account Usage in N8N

Questions
,
1

I am building out a workflow that requires me to send an email. In this case, I want the email to come from a generic or shared email account. I should note that we are using Google Workspace (Gmail) for email. I also don’t want to specify a specific user’s credentials in this workflow since users come and go (even admins like myself). I assume that service accounts are the way to go. I’ve followed ALL instructions I could find and read every forum post on the subject, but I’m still running into issues.

When creating the credential, IF I DON’T select “impersonate a user”, the credential validates successfully, but when I go to try and send an email using the credential, I receive an error stating:

{ "error": { "code": 400, "message": "Precondition check failed.", "errors": [ { "message": "Precondition check failed.", "domain": "global", "reason": "failedPrecondition" } ], "status": "FAILED_PRECONDITION" } }

When creating the credential, if I DO specify “impersonate a user”, then I get an error saving the credential. The error is:

Private key validation failed: 401 - {"error":"unauthorized_client","error_description":"Client is unauthorized to retrieve access tokens using this method, or client not authorized for any of the scopes requested."}

Am I missing a step somewhere or is there a more suggested workflow? In our case, I’ll need to send email out from a “shared mailbox” and I’ll need to access and modify google sheet files located on a shared drive. My only requirement is that a specific real user isn’t used for authentication to prevent my workflow from breaking if someone gets terminated.

Information on your n8n setup

Thanks in advance!

2

As far as my understanding goes, Google service accounts do not have its own mailbox. So when you DO NOT select a user impersonation, it looks like the APIs are refusing to provide the sending service since there is no mailbox connected to the account in use.

On the other hand when you selected an impersonation it throws a 4xx error. Sounds like DWD configuration for permission/scope handling is where the fault lies. Why don’t you use a standard account like, [email protected] for this purpose? so user departuers will not affect the workflow.