Reference · Credentials
Google API credentials
Used by 7 BusyBot nodes.
googleApi 3 fields The Google API credential authenticates as a Google Cloud service account using its email and RSA private key, and is used by 7 BusyBot nodes. Unlike a personal OAuth connection it acts as an application identity, which suits server-side automation — and with domain-wide delegation it can act on behalf of users in a Google Workspace domain.
Fields
| Field | Type | Required | Notes |
|---|---|---|---|
Service Account Emailemail | string | Yes | The service account email address (e.g. my-bot@my-project.iam.gserviceaccount.com) |
Private KeyprivateKey | password | Yes | The RSA private key from the service account JSON key file. Include the full PEM text. |
Delegated Email (optional)delegatedEmail | string | No | If domain-wide delegation is configured, specify the user email to impersonate. |
Getting your credentials
- In the Google Cloud Console, select or create the project the automation should belong to.
- Enable the specific Google APIs the nodes you plan to use require. A service account with no enabled API returns permission errors even when the key is valid.
- Create a service account under IAM & Admin, giving it a descriptive name.
- Create a JSON key for that service account and download it. This is the only time the private key is available.
- From the downloaded JSON, copy
client_emailinto the credential’s Email field andprivate_keyinto the Private Key field, including theBEGINandENDlines exactly as they appear.
Permissions and scopes
A service account is its own identity — it does not automatically see your files or data. Grant it access explicitly:
- For Google Cloud resources, assign IAM roles to the service account.
- For a specific Drive file or folder, share that item with the service account’s email address exactly as you would with a colleague.
- For Workspace-wide access, configure domain-wide delegation in the Google Workspace admin console, authorising the service account’s client ID for the scopes required. Then set Delegated Email to the user to impersonate.
Troubleshooting
- 403 with an API disabled message — the relevant API is not enabled on the project. Enable it and retry.
- 404 or empty results on Drive — the file or folder has not been shared with the service account’s email address.
- Invalid key or JWT signature errors — the private key was reformatted on paste. It must include the header and footer lines and the newlines within it.
- Delegated email rejected — domain-wide delegation is not configured, or the required scopes were not authorised for the service account’s client ID in the Workspace admin console.
Frequently asked questions
Why can the service account not see my Drive files?
Because it is a separate identity, not you. Share the file or folder with the service account's email address exactly as you would with a colleague, or configure domain-wide delegation and set Delegated Email.
What is Delegated Email for?
Impersonating a user in a Google Workspace domain. It only works when domain-wide delegation has been configured in the Workspace admin console and the required scopes authorised for the service account's client ID.
How should the private key be pasted?
Exactly as it appears in the JSON key file, including the BEGIN and END lines and the newlines within. Reformatting it is the most common cause of signature errors.
How is this different from the Google OAuth2 credentials?
This is an application identity for server-side access. The OAuth2 credentials (Gmail, Drive) act as a specific user who granted consent, which is what you want for personal mailboxes and drives.
Nodes that use Google API
One credential works across every node below — create it once and reuse it.
Last updated . Spotted something wrong? Tell us.