Integrating WordPress with a CRM

Before any code, be specific about the data and the direction. 'Integrate with the CRM' covers several different projects.

• One-way, site to CRM: form submissions become leads. The most common and the simplest.
• One-way, CRM to site: the CRM is the source of truth for something the site displays — a product list, a stock level, a team directory.
• Two-way sync: both systems can change the same record. Dramatically harder, because you now need conflict resolution and a rule for who wins.
• Triggered actions: an order in WooCommerce creates a deal, or a status change in the CRM sends an email.
• Most projects need the first, sometimes with the fourth. If someone asks for two-way sync, ask what specifically must be editable in both places — it's often less than they think.

You can call the CRM's API directly from WordPress, or route through an automation platform that speaks to both.

Middleware is faster to set up, needs no code, handles retries and logging for you, and is easy for a non-developer to adjust. It costs a subscription, adds a dependency, and gets expensive at volume.

Direct is cheaper to run, gives you full control over error handling and data shape, and has no third party in the path. It costs development time and you own the retry logic.

A reasonable rule: middleware for low volume and simple mappings, or when nobody will maintain code. Direct when volume is high, when the mapping is complex, or when the data is sensitive enough that you don't want it passing through another service.

This is the rule that matters more than any other. The CRM will be unavailable at some point — maintenance, rate limits, an expired token, a network problem. When that happens, the lead must still exist.

So: write the submission to WordPress first, synchronously, and confirm success to the visitor based on that. Then attempt the CRM send separately. If it fails, the record is still in the database and can be retried or exported by hand.

The anti-pattern is calling the CRM inside the form handler and returning an error to the visitor if it fails. The visitor is told their enquiry failed when it was perfectly valid, and they usually don't try again.

• Push the send onto a queue rather than performing it during the request. A CRM taking four seconds should not make your form take four seconds.
• WordPress's scheduled events work for this on a low-traffic site; WooCommerce's action scheduler is more robust if it's available.
• Retry with exponential backoff — a few seconds, then a minute, then longer. Give up after a bounded number of attempts and flag the record for human attention.
• Distinguish retryable failures from permanent ones. A 500 or a timeout is worth retrying; a 400 because a required field is missing will fail identically forever.
• Make sure retries can't create duplicates, which means the send has to be idempotent.

The same person will submit twice — double-clicking, a network retry, or genuinely enquiring again next month. Without a rule, your CRM fills with duplicate contacts and your sales team calls the same person three times.

Decide the matching key up front. Email address is the usual choice, and most CRMs support an upsert: create if the email is new, update if it exists. Use that rather than always creating.

For genuine repeat enquiries, the right model is usually one contact with several activities or deals attached, not several contacts. Agree this with whoever uses the CRM — it's a process decision as much as a technical one.

More integrations go wrong here than anywhere else, and it's entirely avoidable. Build a mapping document before writing code: every form field, the CRM field it goes to, the type, whether it's required, and what happens if it's empty.

• Watch types. A CRM date field won't accept a free-text date. A picklist won't accept a value that isn't in the list.
• Decide what happens when an optional field is empty — omit it, or send an empty value? These behave differently.
• Handle picklists that change. A new option added in the CRM that the site doesn't know about will cause rejections.
• Include the source and the page in the mapping. Where a lead came from is usually the most valuable field and the one most often forgotten.
• Store UTM parameters if marketing attribution matters, which means capturing them on landing and carrying them through to submission.

• API keys in environment variables or a secrets manager, never in the repository and never in a plugin setting visible to every administrator.
• Use the minimum permissions the integration needs. An API user that can only create contacts can't exfiltrate your customer list.
• Handle token refresh properly if the CRM uses OAuth — an integration that silently stops working after sixty days because nobody implemented refresh is a classic.
• HTTPS for every call, with certificate verification left on.
• Log what was sent and what came back, but not the personal data itself. A log full of customer addresses is a data breach waiting to happen.

A broken integration is silent. Forms keep submitting, visitors keep seeing the success message, and nobody notices for weeks that nothing is reaching the CRM.

• Alert on repeated send failures, not just on a single one.
• Alert on an unusual absence of sends. Zero leads on a Tuesday is as informative as a hundred errors.
• Keep a visible record in WordPress of each submission's send status, so someone can look.
• Reconcile periodically: count submissions in WordPress against records in the CRM for the same period.
• Test the whole path after any plugin, theme or CRM configuration change.

You're sending personal data to a third party, which has consequences regardless of where you operate. Say so in your privacy policy, naming what is sent and to whom.

Collect only what you need. A form asking for a company size and a budget range because the CRM has fields for them is collecting data for its own sake.

Make sure a deletion request can actually be honoured in both systems. If someone asks to be removed and you only delete from WordPress, you haven't done it.