Most WooCommerce integrations fail because they were built for the case where everything works. Real systems time out, send the same message twice, change their API, expire a credential, or return data in a shape nobody planned for. An integration lasts when it is built around those events, not around the happy path.
This guide is for store owners and operations leads who connect WooCommerce to an ERP, CRM, shipping or warehouse (3PL) system, accounting tool or marketing platform. It lists the failure patterns we see described most often in this kind of work, and for each one, what to ask your developer to build in. It describes general engineering practice, not a particular client’s project.
1. The demo only shows the happy path
Every integration demo looks the same: two systems, one clean request, a green tick. The effort in a real integration goes into what happens when that request fails, arrives late, arrives twice or returns something unexpected.
Build in: a written list of failure cases before any code is written. For each connected system, decide what should happen when it is down for an hour, when it rejects a record, and when it answers slowly.
2. Calls made while the customer waits
WordPress waits for an outgoing request to finish, and by default wp_remote_request() gives up after 5 seconds. If checkout calls an outside system synchronously and that system is slow, the customer waits, or the order fails. A slow ERP then becomes a checkout problem.
Build in: keep outside calls out of the checkout path wherever you can. Record the order first, then send it to the other system in the background with a queue. WooCommerce ships with Action Scheduler for exactly this kind of background work, and it keeps a log of each job.
3. The same message arrives twice, or never
Webhooks and retries mean a system may deliver the same event more than once, and a network problem may mean it does not arrive at all. Without protection, the result is a duplicate order in the ERP, a customer added twice, or stock counted off twice.
Build in: make each action safe to repeat (idempotent). Store the other system’s reference against the WooCommerce order, check it before creating anything, and reconcile on a schedule so a missed message is found and fixed later.
4. No retry plan, or an endless one
A single failed call that is never tried again leaves an order stuck in one system. A retry loop with no limit can hammer a service that is already struggling, and can hit its rate limits.
Build in: a limited number of retries with growing gaps between them, a clear “gave up” state, and a way for a person to see and re-send what failed.
5. Failures that nobody sees
This is the most expensive pattern. Orders stop reaching the warehouse, and nobody notices until a customer asks where their parcel is. The integration “works” because it raises no error anyone reads.
WooCommerce’s own webhooks are an example: if deliveries to a URL keep failing, WooCommerce eventually disables that webhook, and the store carries on without telling you.
Build in: a log of every outgoing and incoming call (without storing card or other sensitive data), a count of what is waiting or failed, and an alert when that count grows. Then check it as part of a routine, not only when something goes wrong.
6. Data that does not match
Two systems rarely describe the same thing in the same way. Common mismatches are product SKUs that differ by a space or a case, order statuses that do not map one to one, tax and rounding differences of a cent, currencies, and address formats and required fields.
Build in: one clear mapping for each field and status, written down, with a plan for records that do not fit. Normalise data in one place, in one layer, so a change to a field is made once.
7. Credentials and tokens that expire
API keys get rotated and OAuth tokens expire. An integration that nobody owns stops on the day a token lapses.
Build in: refresh logic for tokens, a visible “connected” status, and a calendar note for anything that has to be renewed by hand.
8. The other side changes
A vendor changes a field name, retires an old API version or tightens a rate limit. Your own updates change things too: a WooCommerce or plugin update can change how an order or its data is stored. Neither side tells the other.
Build in: test the integration on a staging copy after updates on either side, and keep the integration logic in one place so a fix is one change, not five.
9. Nobody owns it
Integrations often outlive the person who built them. Without notes on what talks to what, which credentials it uses and where to look when it breaks, a small problem turns into a long one.
Build in: short documentation: which systems are connected, what flows each way, where the logs are, and who to contact. This is the cheapest part to do and the most often skipped.
A short checklist before you sign off an integration
- Are slow or failed calls kept out of the checkout path?
- Is every action safe to repeat?
- Is there a limited retry plan and a place to see what failed?
- Is there a log, and does something alert you when failures build up?
- Is every field and status mapping written down?
- Do you know when each credential expires?
- Has it been tested on staging after the last update on either side?
- Is there a one-page description of how it works?
Our free WooCommerce Integration Health Checklist turns this into a routine you can repeat.
What a store scan can and cannot tell you
The free KODENZO Commerce Health plugin includes read-only checks of WP-Cron and Action Scheduler health, which matter because most background integration work runs on them. It does not see inside your ERP, your CRM or your 3PL, and it cannot tell you whether a record reached them. It reads your store’s configuration and changes nothing.
Frequently asked questions
Why does my WooCommerce integration work for weeks and then stop?
The usual suspects are an expired token or key, a changed API on the other side, a background task queue that stopped running, or a plugin update. A log and an alert shorten the time it takes to notice.
Should an integration run while the customer checks out?
Only when the customer really needs the answer to continue, for example a live shipping quote. For everything else, save the order first and send it onward in the background.
Is a plugin enough, or do I need custom development?
Often a well-supported plugin is enough for a standard connection. Custom work makes sense when a system has unusual rules, several systems must stay in step, or no plugin handles your failure cases.
Need a hand?
If you have an integration that is unreliable, or one you want built to last, our API and third-party integrations service covers it. A written example of the approach is in our API integration suite case study.