WooCommerce integration that survives the next plugin update
WooCommerce is a WordPress plugin, so the store sits on your own hosting and a dozen plugins from different authors work around the cart. We wire it into what comes next: accounting and e-invoicing, the CRM, the warehouse and a data warehouse. The logic lives outside WordPress, so the next update does not stop your invoices or your stock figures.
- 14 dayshow long it usually takes from the workshop to the first automation running on your own orders
- 2 to 6 weeksfrom the workshop to a full integration, depending on how many plugins and systems stand on the other side
- 5 to 10 secondshow long the AI agent needs to say how many orders from this week still have no invoice
The problem
Why does a WordPress store keep selling while the integrations around it keep breaking?
WooCommerce is a plugin for WordPress, and that changes who maintains what. The store sits on your hosting, so the PHP memory limit, the script execution time and the speed of the database are your problem, not the platform vendor's. A dozen plugins from different authors work around the cart: payments, shipping, invoices, returns, the field for a VAT number. Each has its own release cycle and its own columns in the database.
So there is no single company answerable for the whole thing. When an invoice stops being issued after an update, the invoicing plugin author points at the payment plugin author, the host points at WordPress, and you have orders with no document. The data is not in one place either: part of the order sits in the WooCommerce tables, part in wp_postmeta fields, and the VAT number or the marketing consent sits wherever the plugin that added that field decided to put it.
Some of this work stopped being a matter of convenience. Structured e-invoicing is being made mandatory across EU countries, each on its own timetable, and the filing format is set by the national scheme rather than by your store. When the invoice is created from the order by hand, or by a plugin nobody is watching, every update is a risk inside a process that carries a statutory deadline.
- The invoice stops being issued after a plugin update and nobody notices until the end of the day
- A VAT number from a field some plugin added gets retyped into the accounting software
- An order export from the WordPress admin brings the hosting down in the middle of a selling day
- The last piece sold in the store and on a marketplace, because the stock figure went out a minute late
Why now
What does WooCommerce give you out of the box, and what has to live outside WordPress?
WooCommerce has a documented REST interface, version 3: orders under /wc/v3/orders, products under /wc/v3/products, customers under /wc/v3/customers, and authentication with a Consumer Key and a Consumer Secret. On top of that there are webhooks for order.created, order.updated and product.updated. The methods and fields are described in the official WooCommerce REST API documentation, so an integration never has to dig around in the WordPress database. That is the first condition for surviving an update.
The second condition is about what WooCommerce does not guarantee. A webhook sent while the server is restarting does not retry itself, and WP-Cron, which runs the scheduled jobs in WordPress, only fires when somebody visits the site, so at night it can be hours late. That is why the schedule and the retry queue sit outside the store, in n8n, Make or a custom API integration, and WooCommerce goes back to being the one place where an order has one status.
The third change is the AI agent. A rule will move data from an order into accounting, but it will not answer how many orders from this week still have no invoice and which product comes back most often. BOND, our company AI agent, reads sales, returns and cost of goods at once and answers in a plain sentence in 5 to 10 seconds. We describe the wider flow on the page about e-commerce automation.
What changes
What does the store team get, and what does accounting get?
The order carries on even when a webhook goes missing
The order.created event starts the workflow within seconds, and a control call to /wc/v3/orders picks up whatever did not arrive. Nothing depends on whether WP-Cron fired overnight.
Two routes to the same order: the webhook and a poll every 15 minutes
The invoice is built from the order and goes out for filing
Xero, QuickBooks, sevDesk or Fakturownia get the data straight from the order, together with the VAT number from the invoice field. The document number comes back to WooCommerce as a note on the order, and an accepted return starts a credit note.
The invoice number visible on the order in the admin, with no trip to accounting
Stock counted in one place, marketplace sales included
In the workshop we agree one source of truth for stock: WooCommerce, your ERP or BaseLinker. A paid order reserves the piece at the source, and the new figure reaches the store and the marketplaces within seconds.
One number distributed to every channel, instead of two admin panels fixed by hand
An integration that survives a plugin update
We read and write only through the documented REST interface, never straight into the WordPress tables. Every field a plugin added is mapped explicitly, with an alert on the day it disappears.
Updates checked on a copy of the store first, then on production
Order data kept outside the store database
Sales, returns and cost of goods land in BigQuery or in a sheet every day, read in batches during the night. The report does not load the server your customers are placing orders on.
A per-product breakdown refreshed daily, with no export from the admin
Questions about the store in a plain sentence
How many orders from this week have no invoice, which size comes back most often, how many pieces of this product are left across all channels. The AI agent answers from store, accounting and warehouse data.
An answer in 5 to 10 seconds, with nobody logging into the WordPress admin
And in your store
What if our WooCommerce is buried in plugins?
Four sentences come up more often than any others on WordPress stores. Here is what we answer to each of them.
We already run a dozen plugins and we do not want another one.
And we do not add one. The logic sits outside WordPress and talks to the store through the REST interface and webhooks, so no new code grows inside the store for somebody to maintain later. Sometimes it works the other way round: two plugins doing the same job can be switched off after the rollout.
We are afraid the integration will break at the next update.
That is why we read only from the documented v3 interface, not from database tables that plugin authors change without notice. Updates get checked on a copy of the store first, every plugin field is mapped explicitly, and when one disappears you get an alert the same day instead of silence.
Our hosting is already struggling and you want to add API traffic.
We take heavy work off the store rather than adding to it. Report data is read in batches at night instead of exported from the admin in the middle of the day, and the schedule sits outside WordPress. If the workshop shows that the hosting itself is the problem, we say so plainly, and that is the first thing to fix.
We have no IT team and nobody here knows the WooCommerce API.
Nobody has to. What stays on your side is generating a Consumer Key and a Consumer Secret in the WooCommerce admin and deciding what data may leave. After the rollout we hand over the documentation and train one person in customer service to read the error queue, so they do not raise a ticket for every exception.
- Store and WordPress
- WooCommerce REST API v3, webhooks, WordPress, payment and shipping plugins
- Accounting and invoices
- Xero, QuickBooks, sevDesk, Fakturownia, e-invoicing filing
- Sales and marketplaces
- BaseLinker, Amazon, eBay, Shopify, PrestaShop
- CRM
- HubSpot, Pipedrive, Salesforce, Zoho
- Data and reporting
- BigQuery, Google Sheets, GA4, SQL databases
- Automation layer
- n8n, Make, Zapier, custom API integrations
Events in WooCommerce, where we read them from and what we guard against
Seven events, the ones we usually start from. The third column matters most here, because on a WordPress store an integration falls over not on the data but on whatever turns out to be unreliable along the way.
| Event in the store | Where we read it from | What we guard against |
|---|---|---|
| A new order | the order.created webhook | a webhook is lost when the server restarts, so we add a poll of /wc/v3/orders every 15 minutes |
| A status change | the order.updated webhook | plugins can change a status several times a minute, so the rule works on the final state |
| A stock change | the product.updated webhook and /wc/v3/products | stock comes from one source of truth, so the channels do not overwrite each other |
| A return and a credit note | order status and the fields of the returns plugin | the field lives in a plugin, so we map it explicitly and alert when it stops existing |
| A new customer and consents | /wc/v3/customers and the order data | guests buy without an account, so we match records on email and on the VAT number from the invoice field |
| A scheduled job | a schedule outside the store, not WP-Cron | WP-Cron fires when somebody visits the site, so nightly jobs run on our side |
| Data for a report | /wc/v3/reports and the store database | read in batches at night instead of exported from the admin during selling hours |
A first rollout usually covers two or three events. The rest come in down the same track once the first ones pass their measurement at 30 days.
How we do it
Five steps from a WordPress store to a connected flow
Every step ends with something you can judge before you decide on the next one. Process first, tools second.
Workshop
One week. We walk the path of one of your orders, from the cart to the closing of a return, and note where data gets retyped by hand. We list the plugins that touch the order, the invoice and the stock figure, and what stands on the other side: the accounting software, the ERP, the marketplaces.
Integration design
A list of the events leaving the store, the direction of each stream and one source of truth for stock. We map the fields that plugins added, so it is clear what exactly we read. Then the tool: n8n, Make or an API integration, always the simplest route to the goal.
Pilot on a copy of the store
The flow runs on a copy of the store, alongside your current process, with customer messaging switched off. We replay situations from last season: an update of the invoicing plugin, a guest order with no account and no VAT number, two sales of the last piece in the same minute, a return after 14 days, a webhook missed during a server restart.
Production and training
Once it checks out we switch to production with error monitoring. An off switch stays on your side, along with an error queue that shows what did not go through and why. Somebody in customer service learns to read it and close it, without raising a ticket with us.
Measurement after 30 and 90 days
We check the metrics written down in the workshop: how many orders went through without a person, how many were left without an invoice, how many times stock drifted between the channels. Only then do we add the next event, down the same track.
Before and after
How the day changes for the person running the store
Before
- The morning starts by checking whether overnight orders have invoices and adding the missing ones by hand
- After every update somebody walks the cart step by step to see what broke
- Marketplace stock gets corrected in a second admin panel, based on what the store shows
- Asked about the margin on a product, the answer is I will run an export and get back to you
After
- Overnight orders have an invoice and its number on the order before anyone opens a laptop
- The update goes to a copy of the store first, and the retry queue shows what did not go through
- Stock travels from one source to the store and the marketplaces, with no second admin panel
- Asked about margin, the AI agent answers in 5 to 10 seconds
The first event usually runs in production 14 days after the workshop. The effect on handling time and on the number of orders with no document gets judged after 30 and 90 days, on metrics written down before the start.
For the person signing this off
What the owner of a WordPress store gets out of it
There is no single vendor answerable for your whole store, and that will not change. What changes is the boundary. The logic that invoices and stock depend on stops sitting in yet another plugin and moves into a layer you can test before an update, version, and switch off with one flag. Update risk stops being a lottery.
The second thing is the conversation with your accountant and your board. When sales, returns and cost of goods sit in one place, you know which products are still worth advertising and how many orders are waiting without a document. You start with one event, so the first decision is small and reversible. We write more about this on the page about AI and automation for e-commerce.
- The workshop ends with a document you can execute without us
- The logic sits outside WordPress, so a plugin update does not stop invoices
- The pilot runs on a copy of the store, so the current process works until the tests are done
- Hosting, plugins and tools go straight to the vendors, with no margin from us
What it costs
The workshop has a published price, the integration is quoted after it
The process workshop costs EUR 3,500 net per week and runs from 1 to 7 weeks. A WooCommerce store usually needs one week, two when an ERP or several sales channels come into the flow. We quote the integration after the workshop, because only then is it clear how many plugins touch an order and what state the hosting is in.
Hosting, plugin licences, the subscription for Make or n8n and model usage, at EUR 0.005 to 0.07 per query at provider list prices, you pay the vendors directly. We add no margin and no invoices pass through us.
Process workshop
EUR 3,500 net
per week, usually one or two for a WooCommerce store
A self-contained piece of work. It ends with a map of the order flow and a list of events to connect, in an order you can execute without us.
- A map of the order path from cart to the closing of a return
- A list of the plugins that touch the order, the invoice and the stock figure
- One source of truth for stock, agreed and written down
- A tool recommendation: n8n, Make or an API integration
- The metrics to measure at 30 and 90 days
- Most popular
Workshop and WooCommerce integration
Quoted after the workshop
scope follows from the number of plugins and the systems on the other side
The option most stores choose. A working flow 2 to 6 weeks after the workshop, launched on a copy of the store first.
- Everything in the workshop
- Wiring into accounting and e-invoicing, the CRM and the sales channels
- Webhooks plus a control API poll, a retry queue, alerts on missing fields
- Stock distributed from one source of truth, marketplaces included
- Pilot on a copy of the store, error monitoring, training for your team
WooCommerce and an AI agent
Quoted after the workshop
for stores that ask about orders and margin every day
Everything in the integration plus BOND, which answers from that data in a plain sentence. The agent takes around two months to roll out.
- Everything in the WooCommerce integration
- A warehouse with sales, returns and cost of goods per product
- The AI agent wired into the store, accounting and the data warehouse
- Answers in 5 to 10 seconds, in English and in Polish
- Access for customer service, the warehouse and the owner
The workshop ends with a document that stands up without us: the order flow map, the list of fields and the rollout order. If it turns out that the problem is the hosting, or two plugins doing the same job, we say so plainly rather than building an integration on a shaky foundation. The matter then ends at the workshop, not at a rollout you do not need.
Frequently asked questions
What does a WooCommerce integration actually connect?
It ties the store to what stands on both sides of it: the accounting software and e-invoicing, the CRM, the warehouse, the marketplaces and the data warehouse. New orders, status changes and stock movements leave the store on their own, through the REST v3 interface and webhooks, and results come back onto the order. The logic sits outside WordPress, so we do not add a plugin for somebody to maintain later.
How long does a WooCommerce integration take?
One week of workshop and 2 to 6 weeks of rollout, depending on how many plugins touch an order and how many systems sit on the other side. The first event, usually the invoice from the order, runs in production around 14 days after the workshop. We add the next ones after the measurement, not all at once.
Will the integration survive a WooCommerce and plugin update?
That is what it is designed for. We read and write only through the documented v3 interface, not through the WordPress database tables, because plugin authors change those without notice. Updates get checked on a copy of the store first, and fields coming from plugins are mapped explicitly, with an alert on the day one of them disappears. Failed calls wait in a retry queue instead of vanishing.
Are you adding yet another plugin to WordPress?
No. The store stays as it is, and the flows sit in n8n, Make or a custom integration on our side, talking to WooCommerce over the API. No code grows inside the store, so the list of things that can break at an update does not grow either. It happens that after the rollout you can switch off a plugin that was doing half the same job.
Will the integration handle invoices and e-invoicing?
Yes, and that is the most common first stream. Order data goes to Xero, QuickBooks, sevDesk or Fakturownia, together with the VAT number from the invoice field. Your invoicing software files the document to the scheme in your market, and the number comes back as a note on the order in WooCommerce. An accepted return starts a credit note. If your accounting software already files by itself, we do not duplicate that and take care of what happens before and after.
How does stock sync work when we also sell on marketplaces?
In the workshop we agree one source of truth for stock: WooCommerce, your ERP or BaseLinker. A paid order reserves the piece at the source, and the new figure reaches the store and the marketplaces within seconds. The channels read the same number instead of reading each other, so the last piece does not sell twice. We describe the mechanism itself on the page about <a href="/en/automations/automatic-inventory-update/">automatic inventory updates</a>.
What if our hosting cannot keep up?
Then we say so in the workshop rather than promising that automation will fix it. The integration takes work off the store, because report data is read in batches at night and the schedule sits outside WordPress and does not depend on WP-Cron. But when the database is already choking on the cart itself, the first step is the hosting, not another workflow.
Do we need a developer and access to the WooCommerce API?
No developer. What stays on your side is generating a Consumer Key and a Consumer Secret in the WooCommerce admin and deciding what data may leave. We set the scope of the permissions so the integration reads and writes only what it needs. After the rollout we hand over the documentation and train someone in customer service to read the error queue themselves.
Let us walk the path of one order from your store
The free consultation takes 30 minutes. You tell us how many plugins touch an order, where the invoice is created and what broke after the last update. We show you what can be connected straight away and what needs the store tidied up first. You do not have to share the admin or generate API keys at this point.
We run at most two rollouts at a time, so that someone is actually sitting on each of them.
Book a free consultationPS. If somebody in your company walked the cart step by step after the last update to check that invoices still go out, that is exactly this problem. You write to Paweł, a founder, not to a shared inbox, and you get an answer within one working day.