BlogResources

How to connect WooCommerce to Google Sheets when it is a WordPress site

Connect WooCommerce to Google Sheets without slowing your shop. Covers hosting limits, authentication and plugin-defined order statuses.

Isha MagguIsha Maggu11 min read

Summarize with AI

How to connect WooCommerce to Google Sheets when it is a WordPress site
On this page

To connect WooCommerce to Google Sheets, create a read-only REST API key, export orders incrementally by modified date, and run the export off-peak. WooCommerce runs on your own server, so your hosting, plugins and WooCommerce version shape the export more than anything about the spreadsheet.

Key takeaways

  • A WooCommerce export competes with customers for the same server, so schedule it off-peak and page in modest batches.
  • Use a dedicated read-only REST API key, and test the connection before building anything else.
  • Order statuses are not fixed, because plugins add their own. Report unknown statuses instead of dropping those orders.
  • State the sheet's grain (one row per order or per line item) and which statuses count as revenue.
  • Reconcile revenue against the payment provider, not the shop dashboard.

What we'll cover

It runs on your server

A WooCommerce export runs on your own server, so your reporting query competes with customers. There is no vendor absorbing the load, keeping the API consistent between versions, or checking what a plugin changed in an order.

  • Load: An export pulling thousands of orders during a busy hour uses the same machine that serves the shop.
  • Shared hosting has hard limits. The host kills a request that takes too long, without returning an error you can interpret.
  • A security plugin may block you. Rate limiting and firewall rules apply to your export too, often without a useful message.
  • Caching plugins can serve stale responses to API requests, depending on configuration, so the export is subtly out of date.
  • Your version is whatever you last updated to. The API's behavior differs between versions in ways the documentation assumes you know.

In practice, schedule the export off-peak, page in modest batches, and test against your own installation instead of trusting general documentation.

Authentication, which depends on your setup

WooCommerce authentication uses REST API keys generated in WooCommerce, with read or read-write permissions. A report needs read only. This step fails more often on WooCommerce than on hosted platforms, and the failure is rarely self-explanatory.

  • Use key-based authentication over HTTPS. Confirm the site is actually on HTTPS instead of assuming it.
  • Some hosting strips authorization headers. This produces an authentication failure unrelated to your credentials, and the workaround differs per host.
  • Application passwords are a WordPress-level alternative that some setups prefer.
  • Create a dedicated key instead of reusing one, so you can revoke it without affecting anything else and the access log attributes requests to it.
  • Test the connection before building anything.

Building it with CodeWords

CodeWords connects to 3,000+ integrations (CodeWords integrations directory, 2026), and you make each connection once and reuse it. You describe the outcome and Cody, the automation builder, builds, connects and deploys it.

  1. Open CodeWords and start a new automation.
  2. Describe to Cody what should happen in plain language: which orders, which fields, how often, and which sheet.
  3. Authorize the connection with a read-only WooCommerce API key, plus access to the target spreadsheet.
  4. Describe the exceptions: a request that times out, an order with a status you have not seen, a missing plugin field.
  5. Run it against a staging copy of the site if you have one, and off-peak against production if you do not.

The free plan covers light use. Pro costs $39 per month ($33 per month billed yearly) and Business costs $100 per month (CodeWords pricing page, 2026). Details are on the pricing page.

Order statuses are not fixed

WooCommerce order statuses are not a fixed set, because plugins add their own. The standard set is pending, processing, on hold, completed, cancelled, refunded and failed. A subscription plugin, a shipping plugin or a payment gateway can each introduce more.

  • Report unknown statuses instead of dropping those orders or bucketing them as "other". That is how a whole category of orders vanishes from a report.
  • Statuses mean different things per shop. "On hold" is a payment problem on one shop and a stock problem on another, so document what yours mean next to the sheet.
  • Decide which statuses count as revenue and say so in the sheet. This single decision is why an export disagrees with what the shop owner expects.
  • Refunds are partly separate. A partially refunded order keeps its original total, so a revenue figure needs the refunds subtracted deliberately.

Line items and the grain decision

The grain decision is whether the sheet has one row per order or one row per line item. State the grain prominently, because a wrong grain is the most common cause of a wrong total from an ecommerce export.

  • One row per order keeps counting sensible and loses product detail.
  • One row per line item gives product-level analysis, but the order total appears once per line, so anyone summing it double-counts.
  • If you need both, use two sheets instead of one sheet with a flag, because someone will filter the flag wrongly.
  • Product names change. A line item stores the name at the time of sale, so the same product can appear under several names over time. Group by product identifier.

Meta fields, where plugins put things

Plugins store their data in order meta, and the interesting fields are often there: delivery slots, gift messages, custom checkout fields and subscription references.

  • Meta keys are not documented centrally. Each plugin chose its own, and finding them means inspecting an order.
  • Keys can change when a plugin updates, which breaks an export that depends on one, with no warning.
  • Some meta is internal and meaningless outside the plugin, so exporting everything produces columns of noise.
  • Pick the handful you need, name them readably, and report when one goes missing instead of producing an empty column.

Not taking the shop down with a report

Avoid taking the shop down with a report by exporting off-peak, in small batches and incrementally. Long-running requests are what hosting kills.

  • Schedule off-peak, which for most shops means the early hours in the main market's timezone.
  • Page in modest batches instead of requesting large pages. A big page is a long-running request.
  • Export incrementally with a modified-since filter instead of pulling everything each time.
  • Back off on errors instead of retrying immediately. Timeouts usually mean the server is busy.
  • Watch the site's response times around your scheduled run, at least once, to confirm the export is not what someone complains about later.

Tax, shipping, and the totals that never quite add up

Order totals combine several parts, and an export that treats them casually produces a figure nobody can reconcile. Decide each treatment and write it into the sheet.

  • Tax: Decide whether the revenue figure includes tax. Both answers are defensible and they differ by a lot.
  • Shipping: It is revenue to some businesses and a pass-through to others, with different accounting treatment.
  • Discounts apply at order and line level, so a line item's price may not reflect what was paid for it.
  • Currency: Multi-currency shops store the order currency and, where a plugin provides one, a converted value. Mixing them silently makes a total meaningless.
  • Fees and refunds are separate records attached to the order, not adjustments to its total, so handle both deliberately.
  • Reconcile against the payment provider, not the shop's own dashboard. The gateway knows what money arrived.

Making it survive

Make the export survive by filtering on modified date, writing idempotently and treating timeouts as normal.

  • Filter by modified date and store the cursor durably, so each run is small.
  • Make writes idempotent, matching on order identifier instead of appending blindly.
  • Handle the timeout as a normal case, with a retry and a smaller page size. It is the most common failure here.
  • Report unknown statuses and missing meta fields instead of dropping them silently.
  • Report the outcome: orders exported, rows written, requests retried and anything skipped.

Limits worth knowing about

Five limits shape a WooCommerce to Google Sheets export.

  • Your hosting sets the real limits, including request timeouts and any rate limiting from security plugins.
  • Pagination behavior and available filters vary by WooCommerce version. Check against your own installation.
  • Google Sheets has a cell limit, which a line-item export of a busy shop reaches within a year.
  • Meta field availability depends on plugins. Nothing guarantees a key exists after an update.
  • Deleted orders may not appear, and orders moved to trash behave differently from deleted ones.

What to set up first

Set up an incremental daily export of completed orders at one row per order, filtered on modified date, running off-peak, with unknown statuses reported instead of dropped. It is small, it does not strain the site, and it builds a durable history that the shop's own reporting does not keep in a filterable form.

Two habits make the difference. Use a modified-since filter from the first version, because a full export becomes impractical quickly on shared hosting. And write which statuses you counted as revenue into the sheet, because the shop owner will compare it with their own number and the difference is always definitional.

Frequently asked questions

Why does the export time out?

Your hosting killed a long-running request, which is the most common WooCommerce integration failure. Use smaller pages, filter incrementally, run the export off-peak, and back off instead of retrying immediately.

Why does authentication fail with correct credentials?

Some hosting strips authorization headers, which looks exactly like a credential problem but is not one. Check with your host early, because the workaround differs per host and the error message does not point to the cause.

Why are there order statuses I do not recognize?

Plugins add their own order statuses. Report unknown statuses instead of dropping those orders or bucketing them as "other". Bucketing is how a whole category of orders disappears from a report without anybody noticing.

One row per order or per line item?

Use one row per order for counting and revenue, and one row per line item for product analysis. State the grain in the sheet. Summing the order total on a line-item sheet double-counts, and it is the commonest cause of a wrong ecommerce figure.

Where do plugin fields live?

Plugin fields live in order meta, under keys each plugin chose. No central document lists them. Inspect an order to find them, export only the handful you need, and report when one disappears after an update.

Why does my revenue figure disagree with the shop's?

The difference is usually which statuses you counted and whether you subtracted refunds. Both are decisions, not facts, so write them into the sheet. The gap is almost always definitional and not a data problem.

Will the export slow the shop down?

It can, because the export runs on the same server as the shop. Schedule it off-peak, page modestly, export incrementally, and check the site's response times around a run at least once.

Should revenue include tax and shipping?

Both answers are defensible and they differ substantially, so the sheet must state which one it used. This choice, together with which statuses count, accounts for nearly every "the export does not match" conversation.

What should the export reconcile against?

Reconcile against the payment provider, not the shop dashboard. The gateway knows what money arrived. When the two disagree, the cause is usually refunds, fees or orders in an unexpected status.

Get started today

Your first workflow is free to build.

Describe what you need. Cody handles the build, the connections, and the deployment.