DEV Community: Robert Breen

n8n: Talk to your Google Sheets with an AI Agent (and why it sometimes gets the math wrong)

Robert Breen — Sun, 11 Oct 2026 12:29:51 +0000

Spreadsheets are where a lot of office work lives: the client list, the sales log, the invoice tracker. n8n ships a popular chat template that lets you ask a Google Sheet questions in plain English, and it feels like magic the first time. It also has a habit that surprises people: it is great at looking things up and sometimes confidently wrong at math. Here is how the setup works, and how to keep the answers honest.

I teach this at Stepthrough, so the walkthrough at the end is my own free lesson. The rest of this post stands on its own.

What you are building

Three pieces, wired together on the n8n canvas:

A Chat Trigger that gives you a chat box.
An AI Agent node that reads your question and decides what to do.
A Google Sheets tool the agent can call to fetch rows, plus a chat model (OpenAI, in this case) that does the thinking.

The flow looks like this:

Chat message -> AI Agent -> (chat model + Google Sheets tool) -> answer

The template opens with empty credentials and no data, so the actual work is connecting your own OpenAI key, authorizing Google Sheets, and pointing the tool at a real spreadsheet.

Step 1: Prepare a sheet the agent can read

Agents do much better with a boring, clean table. Use one header row, one record per row, and no merged cells. A made-up example for a small consulting firm:

Client	Industry	Invoice	Status	Due
Harbor Dental	Healthcare	4200	Paid	2026-09-30
Brightline Legal	Legal	6800	Overdue	2026-09-15
Maple Accounting	Finance	3100	Open	2026-10-20

Clear column names matter more than you think. The agent reads them to figure out what it can ask for.

Step 2: Connect the Google Sheets tool

Open the Google Sheets tool node, choose your credential, then pick the document and the sheet. Set the operation to read rows. A common mistake is leaving the tool on a placeholder document, which makes the agent say the sheet is empty when it simply is not looking at yours.

A tool description helps the agent decide when to use it. Something like:

{
  "name": "client_invoices",
  "description": "Returns every row of the client invoice sheet. Columns: Client, Industry, Invoice, Status, Due."
}

Step 3: Give the agent a short system prompt

Without guidance the agent improvises. A few plain sentences go a long way:

You answer questions about the client invoice sheet.
Always read the sheet before answering.
If the answer needs a calculation, show the rows you used.
If you are not sure, say so instead of guessing.

Step 4: Ask it things

Try lookups first: "Which clients are overdue?" or "When is Maple Accounting due?" These work well because the agent only has to find rows and quote them.

Why it sometimes gets the math wrong

Now ask: "What is the total of all open and overdue invoices?" Sometimes you get 9,900 (correct), and sometimes a number that is close but off.

The reason is that a language model predicts text. It is not a calculator. When it adds a column of numbers, it is producing what a plausible sum looks like. With three rows that usually works. With three hundred, rows get skipped, duplicated, or truncated, because the tool may only hand back part of the sheet and the model does not always notice.

Three habits that fix most of it:

Make it show its work. Asking for the rows it used lets you spot a missing record in seconds.
Do the math outside the model. Add a Summary column or a pivot tab in the sheet itself and have the agent read that figure. The spreadsheet is a calculator; let it be one.
Watch the row limit. If the sheet is long, filter before returning rows, for example only Status = Overdue, so the model is not asked to hold the whole table in its head.

A good rule of thumb: use the agent for finding and explaining, and use formulas for adding. If a number is going into a report or an email to a client, check it against the sheet once.

Where this is useful in an office

A bookkeeper asking "who has not paid in 30 days?" without building a filter.
An account manager checking a client's renewal date mid-call.
An operations lead getting a plain-English summary of a weekly log before a meeting.

None of that requires code beyond what you have seen above, and none of it should touch real client data while you are still learning. Practice on a made-up sheet first.

Try it step by step

If you would rather click through it than read about it, I built a free practice version. You work in a practice copy of the n8n editor, it checks each step, and nothing touches your real accounts. It takes about 8 minutes:

n8n: Talk to Your Google Sheets with ChatGPT (free lesson)

Have you hit the "confident wrong number" problem with an agent in your own workflows? I would like to hear how you solved it.

n8n: Swap SerpApi for a Cheaper Search API in 5 Minutes

Robert Breen — Fri, 09 Oct 2026 13:05:37 +0000

If you have an n8n workflow that pulls Google results through SerpApi, the search call is usually the most expensive part of the run. The good news is that it's also the easiest part to swap. It's one HTTP Request node. The trigger, the parsing, the sheet and the email after it don't care which provider answered, as long as the fields come back with the same names.

This post walks through moving one real-world style workflow from SerpApi to Litescrape, a third-party search-results API for Google, Bing and Maps data. It's priced as a cheaper alternative. The whole change comes down to four edits in one node:

Change the URL.
Delete two query parameters.
Move the API key into a Bearer Auth credential.
Test.

The workflow we're changing

Here's the example. Northpeak Packs (made up) sells backpacks. Every Monday at 8:00, an n8n workflow checks competitor prices for "20L commuter backpack" on Google Shopping and adds them to a Google Sheet.

Schedule Trigger (Mondays 8:00)
  → HTTP Request "SerpApi Google Shopping"   GET serpapi.com
  → Split Out                                 field: shopping_results
  → Edit Fields                               date, store, price
  → Google Sheets: Append row in sheet        "Competitor prices" / Weekly

The sheet has five columns: Date, Store, Product, Price, Was. "Was" holds the old price when something is on sale.

The HTTP Request node is the only node that changes. The rest of this post is about that one node.

What the SerpApi call looks like today

With SerpApi, every search goes to the same endpoint, and the engine parameter picks the search type. The key travels as a query parameter.

Setting	Value
Method	GET
URL	`https://serpapi.com/search.json`
Authentication	None
Specify Query Parameters	Using Fields Below

Query parameters:

Name	Value
engine	google_shopping
q	20L commuter backpack
gl	us
hl	en
num	5
api_key	(your SerpApi key)

That last row is worth a second look. Because the key is in the query string, it's sitting in plain text in the node. It can end up in execution logs and in any JSON you export or share. Moving providers is a good excuse to fix that too.

Step 1: Point the node at Litescrape

Litescrape uses one endpoint per search type, not one endpoint plus an engine parameter. For Google Shopping it's:

https://api.litescrape.com/api/google/shopping

Open the HTTP Request node (double-click it) and replace the URL with that address. Leave Method on GET.

If you work with SerpApi's other engines too, the pattern is the same. Look up the matching Litescrape endpoint in its docs, and don't assume the path.

Step 2: Delete `engine` and `api_key`

Under Query Parameters, most rows stay exactly as they are. q, gl, hl and num have the same names in Litescrape, so leave them alone.

Delete two rows with the trash icon:

engine. The URL already says Google Shopping, so this parameter has no job anymore.
api_key. Litescrape wants the key in a header, never in the URL.

You're left with:

Name	Value
q	20L commuter backpack
gl	us
hl	en
num	5

Step 3: Send the key in a Bearer Auth credential

Litescrape expects the key in the Authorization header as a bearer token:

Authorization: Bearer YOUR_LITESCRAPE_API_KEY

You could add that as a header in the node. Don't. Use a credential instead, so the key is stored encrypted and never shows up in the workflow JSON.

In the HTTP Request node:

Scroll up to Authentication and choose Generic Credential Type. That's the option for any service n8n doesn't have a built-in node for.
Set Generic Auth Type to Bearer Auth. It sends Authorization: Bearer <token>, which is exactly what Litescrape asks for.
Open the Bearer Auth credential drop-down and click + Create new credential.
Paste your Litescrape API key (from the Litescrape dashboard) into Bearer Token.
Click Save. n8n names it "Bearer Auth account" by default. Rename it to something like "Litescrape" so you can find it later.

Here's the finished node, as far as it matters:

{
  "name": "Litescrape Google Shopping",
  "type": "n8n-nodes-base.httpRequest",
  "parameters": {
    "method": "GET",
    "url": "https://api.litescrape.com/api/google/shopping",
    "authentication": "genericCredentialType",
    "genericAuthType": "httpBearerAuth",
    "sendQuery": true,
    "queryParameters": {
      "parameters": [
        { "name": "q",   "value": "20L commuter backpack" },
        { "name": "gl",  "value": "us" },
        { "name": "hl",  "value": "en" },
        { "name": "num", "value": "5" }
      ]
    }
  },
  "credentials": {
    "httpBearerAuth": { "name": "Litescrape" }
  }
}

(That's trimmed to show the settings you change. Don't paste it over your node. Make the edits in the editor so n8n keeps the node's ID and connections.)

Also rename the node from "SerpApi Google Shopping" to "Litescrape Google Shopping". If any later node refers to it by name, like $('SerpApi Google Shopping'), update those expressions too, or they'll break.

Step 4: Test one step, then the whole run

Click Execute step in the node. It sends exactly one request, so it costs one call.

The response comes back in shopping_results, and each result has the fields the next nodes already use:

{
  "search_information": { "query_displayed": "20L commuter backpack" },
  "shopping_results": [
    {
      "position": 1,
      "title": "Trailhaven Metro 20L Backpack",
      "source": "Trailhaven",
      "price": "$89.00",
      "extracted_price": 89,
      "rating": 4.6,
      "reviews": 1240
    },
    {
      "position": 2,
      "title": "Cityline Gear Daypack 20L",
      "source": "Cityline Gear",
      "price": "$74.99",
      "extracted_price": 74.99,
      "old_price": "$94.99"
    }
  ]
}

(The stores and prices are made up for the example.)

Check these four things in the output:

The array is still called shopping_results, so Split Out still finds it.
title, source, price and extracted_price are there with the same names.
old_price only shows up on items that are on sale. That was true before too, but it's worth making sure your Edit Fields mapping handles a missing value.
Numbers like extracted_price come back as numbers, not text.

If your Edit Fields node maps them like this, nothing downstream changes:

Date     {{ $now.toFormat('yyyy-MM-dd') }}
Store    {{ $json.source }}
Product  {{ $json.title }}
Price    {{ $json.extracted_price.toFixed(2) }}
Was      {{ ($json.old_price ?? '').replace('$', '') }}

Close the node and click Execute workflow to run the whole thing once. Then open the sheet and look at the new rows. You're checking the actual rows, not the green checkmarks. Green means the node ran. It doesn't mean the data is right.

If the run looks good and the workflow was already published, click Publish again so the live version uses the new node. Saving alone doesn't change what runs on Monday.

If something goes wrong

401 or "unauthorized". The key isn't reaching the API. Check that Authentication is Generic Credential Type → Bearer Auth, that the right credential is selected, and that you pasted only the key, with no "Bearer " in front. n8n adds that part for you.
Results are empty. Check that the q parameter survived the edit, and that you deleted engine and not q by mistake.
Split Out says the field doesn't exist. Open the HTTP Request output and confirm the array name. If you changed endpoints (for example, from Shopping to regular Google search results), the array name changes too, and Split Out needs the new name.
Expressions in later nodes are red. You renamed the node, and an expression still points at the old name.

Before you cancel the old plan

Two habits make a swap like this boring, in a good way:

Run both for a week. Duplicate the workflow, point the copy at Litescrape, and write to a second tab. Compare the products, positions and prices on Monday. Search results move around between providers and between hours, so you're looking for "same kind of data", not identical rows.
Check the pricing pages yourself. Litescrape gives you 5 free calls to try it, then works on prepaid credits. SerpApi works on monthly plans. Check litescrape.com/pricing and SerpApi's pricing page against how many searches you actually run, because the cheaper option depends on your volume.

And whichever provider you use, keep the key in a credential, never in the URL.

Practice it first, without a real key

I turned this exact swap into a free, hands-on practice lesson. You click through a practice copy of n8n, change the URL, delete the two parameters, set up the Bearer Auth credential and check the sheet. It takes about 7 minutes, and it doesn't use any n8n, Litescrape or Google account. No request is sent, and the API key is a placeholder.

Disclosure: I run Stepthrough, and Litescrape is one of its partner lessons.

Free lesson: Litescrape in n8n: swap SerpApi for a cheaper search API