Integrating a CRM or ERP with WooCommerce is the project, not a feature on the side of one. Sending an order to the other system when everything works is a small part of the work. The rest is what happens when the token has expired, the API says slow down, the request times out halfway through, the same order arrives twice, or the other system is down for the weekend. An integration that has not been built for those cases will fail on them, quietly, and the failures will be discovered by the warehouse or the finance team weeks later.
The happy path is the short part
Every integration demo looks the same: place an order, watch it appear in the CRM. That takes a day to build against most modern APIs. The reason integrations go over budget and then get abandoned is that nobody scoped the other ninety percent: the conditions under which the two systems disagree, and what the code does about it.
Authentication and token expiry
Most CRM and ERP APIs use OAuth or a similar scheme with short-lived access tokens and a refresh token to renew them. The first version of an integration works because someone pasted a fresh token in. It stops working an hour, a day or ninety days later, depending on the platform, and it stops silently unless the code was written to notice. Build it so that the token is refreshed before it expires, so that a failed refresh raises an alert to a named person rather than a log entry nobody reads, and so that the credentials live in configuration, not in the code.
Rate limits
Every hosted API limits how many requests you may send per second, minute or day, and returns an error when you exceed it. A store that gets a burst of orders during a sale, or a nightly stock sync that walks twenty thousand products, will hit the limit. The code has to read the rate limit response, back off for the period the API specifies, and resume, rather than fail the batch or, worse, retry immediately and make it worse.
Retries and idempotency
Network calls fail. A request can time out after the other system has processed it but before the response arrived, which means your side thinks it failed and the other side thinks it succeeded. If the code simply retries, you get a duplicate. The fix is idempotency: every request carries a key, usually the WooCommerce order ID or a hash of the payload, and the receiving side is told, or checks, that a record with that key already exists. Where the API supports an idempotency header, use it. Where it does not, look up before you create. Retries should be limited in number, spaced with increasing delays, and logged with the reason each attempt failed.
Duplicate orders
Duplicates come from more than retries. WooCommerce fires order hooks more than once in some flows, a status can change twice in quick succession, a payment gateway webhook can arrive before or after the order status hook, and a store manager editing an order can trigger the same event as a customer placing one. Each of these can send the order again. The integration needs a record, stored on the WooCommerce side, of which orders have been sent, with the remote ID they were given, and it needs to check that record before sending.
Partial failures
An order sync is rarely one request. It may be a customer lookup, a customer create if missing, then the order, then the line items, then a status update. If step three fails, steps one and two have already happened. Naive code leaves a customer record with no order attached and retries from the beginning next time, creating a second customer. The integration has to treat the sequence as a unit: record how far it got, resume from that point, and never repeat a step that succeeded.
Webhooks or polling
Data has to flow in both directions: orders out to the ERP, stock levels and prices back to the store, contacts and deal stages back and forth with the CRM. There are two ways to receive changes. Webhooks, where the other system calls your site when something changes, are immediate and cheap but are delivered at most once by many platforms, may arrive out of order, and are lost if your site was down at that moment. Polling, where your site asks for changes on a schedule, is reliable and simple but delayed and costs requests against the rate limit. The correct answer for most integrations is both: webhooks for speed, a periodic reconciliation poll to catch anything missed. Every webhook endpoint needs to verify the sender, respond quickly, and hand the actual work to a background queue.
When the other system is down
The ERP will go down for maintenance. The CRM vendor will have an outage. Your store must keep taking orders regardless, which means the integration can never sit in the checkout request path. Orders are queued, and a background process, typically Action Scheduler, which ships with WooCommerce, works through the queue with the retry rules above. When the other side comes back, the queue drains and nothing was lost. When it stays down longer than expected, someone is alerted, and the store manager can see in the admin which orders are waiting.
Logging that someone can actually use
Every request, response, retry and failure gets logged with the order ID, the timestamp, the direction and the outcome, in a place a non-developer can search. WooCommerce has a built-in logger and a screen for reading it; use that or a custom admin page, not a text file on the server. The test of the logging is a question: "the ERP says it never received order 48213, what happened?" If the answer takes a developer and an hour, the logging is not done.
Who owns the field mapping
The technical work above is the part developers get wrong. Field mapping is the part clients get wrong, and it is the bigger risk. Which WooCommerce field feeds the ERP's customer reference? What does the CRM do with a billing company name that is empty? Which of the store's seven order statuses correspond to the ERP's three? What happens to a product variation that has no SKU? The developer can list every field on both sides and propose a mapping. The business has to decide it, in writing, before the build, and has to own it afterwards, because the mapping will change when someone adds a field to the CRM without telling anyone. Get the mapping into a document that both sides sign, and put a version of it in the plugin's settings screen so that the next change does not need a developer.
What this means for the scope
When you ask for a quote, ask for each of the items above to be named in the scope: token refresh and alerting, rate limit handling, idempotent retries, duplicate protection, partial failure recovery, webhook plus reconciliation, queueing with an admin view, searchable logging, and a signed field mapping. A quote that covers only "sync orders to the CRM" has scoped the demo, and you will pay for the rest as change requests or as a rebuild. This is the standard we hold our own custom plugin development work to, since an integration built well is a WooCommerce extension with a queue and a log, and one built badly is a liability wired into the checkout.
If you are looking to hire a WooCommerce developer for an integration, the useful question is not "have you connected WooCommerce to this CRM before" but "what does your integration do when the CRM is down". The answer tells you whether they have shipped one that lasted. The same rule runs through all of our WooCommerce development work: the unhappy path is the specification.
Common questions
Should I use an off-the-shelf connector plugin or build the integration?
Use a connector if one exists for your exact CRM or ERP, it is maintained, and your field mapping fits its model. Build when the mapping involves your own business rules, when the connector handles failures by dropping records, or when the ERP is a system nobody has written a connector for. Many stores start on a connector and outgrow it at the partial-failure stage.
How do I know if orders are going missing right now?
Reconcile. Pull a day of orders from WooCommerce and the same day from the CRM or ERP and compare the counts and IDs. If the integration cannot produce that comparison itself from its own log, that is the first thing to add.
Can the integration slow down my checkout?
Only if it was built to run inside the checkout request, which it should not be. A correctly built integration records the order and hands the sync to a background queue. The customer never waits on the ERP.
What happens when the CRM changes its API?
Vendors version their APIs and retire old versions on a schedule. The integration should pin a version, log a warning when the vendor announces deprecation, and be maintained by someone who will do the upgrade. This is a maintenance cost, and it belongs in the plan from the start.
Next step
If you have an integration to build, or one that is losing orders, tell us which systems are involved and what is going wrong. The developer who would do the work will reply.
Want a senior developer to look at your site?
Tell us what you need. You get a written scope and a fixed price, usually within one business day.
