Shopify to Google Sheets —
orders, inventory, and
the limits nobody mentions.

When a customer completes checkout, Shopify can fire an orders/paid webhook — a JSON payload containing the order ID, line items, customer details, totals, discounts, and fulfilment status — to any URL you configure in Settings → Notifications → Webhooks. Everything downstream depends on that one event.

There are two free ways to turn that payload into rows in a spreadsheet:

Route 1 — Make.com (no code)

A Webhooks module receives the payload, a Google Sheets Add a Row module writes it. This is the fastest route to something working, and it's what the rest of this guide builds on — see the actual scenario structure below.

Route 2 — Google Apps Script (zero external tools)

A Web App deployed from inside the Sheet itself, listening for the same webhook via doPost(e). No Make.com account needed, but subject to Apps Script's own execution limits — covered in full in why Apps Script hits quota walls at volume.

function doPost(e) {
  var sheet = SpreadsheetApp.getActiveSpreadsheet().getSheetByName('Orders');
  var data = JSON.parse(e.postData.contents);

  data.line_items.forEach(function(item) {
    sheet.appendRow([
      data.id,
      data.created_at,
      data.email,
      item.sku,
      item.title,
      item.quantity,
      item.price,
      data.total_price,
      data.fulfillment_status || 'unfulfilled'
    ]);
  });

  return ContentService.createTextOutput('SUCCESS').setMimeType(ContentService.MimeType.TEXT);
}

Note the forEach over line_items — a three-item order should produce three rows, one per SKU, not one row per order. Most CSV export apps flatten this into a single row per order and lose per-product detail. Either free route above beats a $29–$99/month export app on cost; which one you pick depends on volume and whether you want a Make.com account in the loop at all.

Inventory sync is not the same problem as order export, for three specific reasons:

• Different trigger. Stock changes fire the inventory_levels/update webhook, not orders/paid — and it fires per SKU per location. One order touching three variants across two locations can trigger up to six separate inventory events.
• The payload doesn't include a product name. It carries inventory_item_id and location_id, both opaque numeric IDs. You need a lookup — either a cached mapping tab you build once via the Shopify API, or a live API call per event — to turn that into a readable SKU.
• You want one row per SKU, not an endless log. Appending a new row on every stock change (the same pattern that's correct for orders) turns an Inventory tab into an unreadable history instead of a current-state view. Inventory needs an update, keyed on SKU + location, not an append.

Make.com doesn't run inside Apps Script's execution environment, so the Apps Script quotas above don't apply to it. But every write it makes still goes through the Google Sheets API, which enforces its own independent quota. Per Google's published Sheets API usage limits: 300 read requests and 300 write requests per minute per project, with a 60-per-minute cap per user, and no daily limit.

A typical store's order volume is nowhere near this. It becomes relevant in two specific cases: a scenario writing one API call per line item on large multi-item orders during a traffic spike, or an Iterator module (see the scenario structure below) misconfigured to make far more calls than the order data actually requires. Hitting it returns a 429: Too many requests — Make.com's built-in retry with backoff handles this automatically, but it's worth knowing the ceiling exists independently of anything Apps Script imposes.

Tab 1 — Orders (append-only, one row per SKU)

Tab 2 — Inventory (update-in-place, one row per SKU + location)

Columns A and C in Inventory together form the search key Make.com's "Update a Row (Search Column)" module matches against — the same SKU at two locations needs two rows, not one.

• Approaching the cell ceiling. Google Sheets caps a spreadsheet at 10 million cells total across every tab (Google announced a 20-million-cell beta in April 2026, but 10M is the standing limit). A 9-column Orders tab hits that around 1.1 million rows.
• Formula slowdown, well before the cell ceiling. SUMIF and VLOOKUP ranges recalculating across tens of thousands of rows visibly lag in the UI long before you're anywhere near 10 million cells — this is usually the first real symptom, not the row count itself.
• Concurrent-write friction. Sheets was not built for high-frequency transactional writes from multiple sources. A busy store running order writes, inventory updates, and a reconciliation pass through the same spreadsheet can start to see write conflicts or queuing under sustained load.

When any of these show up consistently, the fix isn't a bigger spreadsheet — it's moving the system of record off Sheets. BigQuery is the natural next step if you're already in the Google ecosystem; a hosted Postgres instance or Airtable base works too. Keep Sheets as a lightweight view or export target on top, rather than the primary store, if you still want the formula-based reporting this guide is built around.