Google Drive
What it is
A Google Drive connection lets workflows list files in a folder, download their contents, and upload files a workflow produced. It is a separate connection from Google Sheets, and deliberately so: a Drive connection asks for access to your files, and a Sheets connection does not.
Before you start
Decide between a person's access and a service account. A connection authorized by signing in acts as that person and can reach exactly the files they can; when their account is disabled, the connection stops working. A service account has its own identity, and only sees folders that have been shared with its address.
If you only need to read and write spreadsheets, create a Google Sheets connection instead. It asks for a much narrower grant.
Setup fields
These are the fields the guided setup collects — both the Add integration form and the setup card Barry raises in chat. Additional settings live on the connection's settings page once it exists.
Connection settings
| Field | Type | Required | Secret | Notes |
|---|---|---|---|---|
name | Text | Yes | No | Display name for this connection. This is what you pick from in a workflow node. |
authMethod | Choice | Yes | No | How Honeybase authenticates to Google — sign in through Honeybase, use your own OAuth client, or use a service account. |
Credentials
This integration has 3 credential options. You supply the fields for the one you pick.
Sign in with Google through Honeybase
The quickest option. You approve access in a Google consent screen and Honeybase holds the OAuth client; nothing to create in Google Cloud.
No credential fields are collected for this option in the guided setup.
Your own Google OAuth client
Your organization's own OAuth client, so consent, branding and revocation stay in your Google Cloud project. Access is still granted by a person signing in, and inherits that person's access to each file and folder.
| Field | Type | Required | Secret | Notes |
|---|---|---|---|---|
auth.clientId | Text | Yes | No | The OAuth client ID from your Google Cloud project, ending in .apps.googleusercontent.com. |
auth.clientSecret | Password | Yes | Yes | The OAuth client secret issued alongside that client ID, from the same Credentials page. |
Google service account
A non-human identity that belongs to no one's account. The right choice for unattended automation — nothing breaks when someone leaves — but each folder must be shared with the service account's address explicitly.
| Field | Type | Required | Secret | Notes |
|---|---|---|---|---|
auth.serviceAccountJson | JSON | Yes | Yes | The service account key file, pasted whole. Google gives you this JSON once, at key creation, and will not show it again. |
The guided setup does not ask for OAuth scopes. Open the connection on the Integrations page to change them.
Sign in through Honeybase
- Choose Sign in through Honeybase as the authentication method and save the connection.
- Click Connect. Google asks you to approve access to your Drive.
- After you approve, you are returned to Honeybase and the connection is ready.
Nothing to configure in Google Cloud — Honeybase owns the OAuth client.
Your own OAuth client
- In the Google Cloud console, pick a project and enable the Google Drive API under APIs & Services → Library.
- Configure the OAuth consent screen for your organization.
- Under APIs & Services → Credentials, choose Create Credentials → OAuth client ID, type Web application.
- Add the redirect URI Honeybase shows on the setup form to Authorized redirect URIs.
- Copy the client ID and client secret.
Service account
- In IAM & Admin → Service Accounts, create a service account.
- On its Keys tab, choose Add Key → Create new key → JSON. The file downloads once and cannot be retrieved again.
- Paste the whole JSON document into the setup form.
- Share each folder with the service account's email address, exactly as you would with a colleague. This is the step people miss: without it, the connection authenticates fine and then reports that the folder does not exist.
Scopes
A Google Drive connection requests full Drive access. Listing and downloading would work with less, but uploading a file into a folder the connection did not create requires the full scope, so it is requested up front rather than forcing everyone who authorized the connection to consent again the first time a workflow uploads.
If a workflow reports that the connection is not authorized for Drive, it was created before this connection type existed and is still carrying a narrower grant — reconnect it to fix that.