n8n Google Sheets Integration: How to Read, Write, and Automate Spreadsheet Workflows

Google Sheets is the default data layer for teams that have not yet committed to a more specialised tool — and often even for teams that have. It is flexible, accessible, and familiar. Connecting it to n8n turns a static spreadsheet into a live part of your automation infrastructure: a trigger surface, a data store, a reporting destination, and a configuration source for other automations. For the equivalent integration in Make.com, see Make.com Google Sheets Integration.

This tutorial covers the complete n8n Google Sheets integration: authentication, the key nodes, practical workflow patterns, and the details that matter in production.

Setting Up Google Sheets Authentication in n8n

n8n connects to Google Sheets using OAuth2. You need a Google Cloud project with the Google Sheets API enabled and OAuth credentials configured. Here is the process.

Create a Google Cloud project. Go to console.cloud.google.com, create a new project, and navigate to APIs and Services > Library. Search for Google Sheets API and enable it. Also enable the Google Drive API, which n8n requires for spreadsheet discovery.

Create OAuth credentials. In APIs and Services > Credentials, click Create Credentials and choose OAuth 2.0 Client IDs. Set the application type to Web Application. Add your n8n instance URL plus /rest/oauth2-credential/callback as an authorised redirect URI. For example: https://n8n.yourdomain.com/rest/oauth2-credential/callback.

Add the credentials to n8n. In n8n, go to Settings > Credentials and create a new Google Sheets OAuth2 API credential. Paste your Client ID and Client Secret from the Google Cloud console. Click Connect and complete the OAuth flow in the browser popup.

For self-hosted n8n, the Google Cloud project needs to be in production mode or your Google account needs to be added as a test user during development. Published apps with proper verification bypass this requirement. If you haven't set up your n8n instance yet, n8n Self-Hosted Setup covers that first step.

The Key Google Sheets Nodes in n8n

Google Sheets Trigger. Polls a specified sheet at a configurable interval and fires when new rows are detected. Use this as a workflow trigger when you want to respond to data added to a sheet by a human or another system. Note that this is polling, not a true event webhook — there is a delay between the row being added and the trigger firing based on your poll interval.

Google Sheets Read Rows. Reads rows from a specified sheet with optional filtering. Returns all matching rows as items for downstream processing. Use this to retrieve data for processing, to look up existing records, or to load configuration data that drives workflow logic.

Google Sheets Append Row. Adds a new row to the end of a specified sheet. Maps node input data to column values. Use this to log events, capture lead data, record processed results, or add any new record to a sheet.

Google Sheets Update Row. Modifies specific cells in an existing row identified by a row number or a matching column value. Use this to update the status of a record, add results to an existing row, or mark rows as processed.

Google Sheets Delete Row. Removes a row from the sheet. Use with care in production; deletions are irreversible without a backup.

Google Sheets Clear Row. Empties cell contents without removing the row. Useful for resetting records without shifting subsequent row numbers.

Pattern 1: Google Sheets as a Workflow Trigger

The most common n8n Google Sheets pattern is using a sheet as an input queue. A human or another system adds rows to a sheet, and n8n processes them.

Practical example: a sales team adds new prospect names and company websites to a Google Sheet. When a new row is detected, n8n triggers a workflow that: looks up the company domain using an enrichment API, retrieves the decision-maker email from Hunter.io, creates a contact in the CRM, and adds the prospect to an outbound email sequence.

Workflow structure:

1. Google Sheets Trigger on the prospects sheet
2. HTTP Request node to company enrichment API with the website URL
3. HTTP Request node to Hunter.io for email lookup
4. CRM node to create the contact with enriched data
5. HTTP Request node to queue the contact in the outbound sequence tool
6. Google Sheets Update Row node to mark the row as Processed in a status column

The status column update in step 6 is important. It prevents the same row from being processed again on the next poll cycle. Use a column named Status or Processed and update it to Done or a timestamp when processing is complete. Configure the trigger to only fire on rows where the Status column is empty.

Pattern 2: Writing Automation Results to Sheets

The inverse of the trigger pattern: n8n runs a workflow and writes the results to a Google Sheet for review, reporting, or downstream use.

Practical example: an n8n workflow runs daily, queries the GoHighLevel API for all opportunities that changed status in the previous 24 hours, and writes a summary row for each one to a reporting sheet. The sales manager opens the sheet each morning and sees the previous day's pipeline activity without logging into GHL — the same reporting pattern that's useful alongside the pipeline structure in GoHighLevel Pipelines Tutorial.

Workflow structure:

1. Schedule Trigger (daily at 7am)
2. HTTP Request node to GHL API for opportunities modified in last 24 hours
3. Split In Batches node to process each opportunity individually
4. Set node to extract and format the relevant fields
5. Google Sheets Append Row node to write each opportunity to the report sheet

The Set node in step 4 is worth spending time on. Format dates, round numbers, handle empty fields gracefully, and combine fields where needed (full name from first and last name fields). The sheet should be readable by a human without requiring decoding.

Pattern 3: Lookup and Conditional Update

A common pattern for keeping a sheet in sync with another system: look up whether a record exists, update it if it does, create a new row if it does not.

Workflow structure:

1. Trigger (webhook, schedule, or external event)
2. Google Sheets Read Rows node with a filter on a unique identifier column (email, ID, order number)
3. IF node: does the Read Rows result contain any rows?
4. True branch: Google Sheets Update Row using the row number from the Read Rows output
5. False branch: Google Sheets Append Row to add a new record

The key is extracting the row number from the Read Rows output. In n8n, when Read Rows returns results, each result includes a _rowNumber field with the sheet row number. Use this in the Update Row node to target the correct row.

Pattern 4: Using Sheets as a Configuration Store

A powerful but underused pattern: store automation configuration in a Google Sheet and have n8n read it at runtime. This allows non-technical team members to adjust automation behaviour without touching n8n.

Example: a follow-up sequence automation sends different messages based on the lead source. The message templates are stored in a Google Sheet with columns for lead source, day number, channel (email or SMS), and message content. When the workflow runs, it reads the configuration sheet to get the right message for the current context.

This separates the logic (in n8n) from the content and configuration (in the sheet). The team that owns the messaging can update the templates directly without a developer touching the workflow.

Handling Large Datasets

Google Sheets API returns a maximum of one range per request, but n8n handles pagination within the Read Rows node automatically when you set the Return All option. For large sheets with thousands of rows, this means n8n makes multiple API requests in sequence to retrieve all data.

For very large datasets, be aware of two constraints. First, the Google Sheets API rate limit is 60 requests per minute per project. High-volume reads that trigger many sequential API calls can hit this. Add a Wait node between batch processing steps if you encounter rate limit errors.

Second, n8n's memory constraints. Processing ten thousand rows in a single execution requires holding all that data in memory simultaneously. For large-scale operations, use the Split In Batches node to process data in chunks and use n8n's execution data retention settings to avoid accumulating large execution logs.

Tip: Use Sheet Names, Not Sheet IDs

When configuring Google Sheets nodes in n8n, you can reference sheets by name rather than by the internal sheet ID. Names are more readable and easier to maintain. Just make sure the sheet name is stable — if someone renames the tab in Google Sheets, the n8n node will break. Consider noting in the sheet itself that the tab name is used by automation and should not be changed without updating the workflow.

When you are validating the JSON structure that the Google Sheets node returns before mapping it to downstream nodes, the JSON Formatter makes the nested structure visually clear.

Building Something Specific?

The n8n Google Sheets integration covers a wide range of practical data automation scenarios. The patterns above — trigger on new rows, write results to a reporting sheet, lookup and update, configuration store — handle the majority of real-world use cases. This kind of configuration-store pattern is one I use often when building automations for clients whose team needs to update messaging or logic without touching the workflow itself.

If you want help building a specific n8n Google Sheets workflow or are running into issues with authentication, row lookup, or large dataset handling, book a free 30-minute call. Bring the sheet structure and the automation outcome you need and we will work through the implementation together.