WordPress integration with CRM is performed via a ready-made connector, webhook, or REST API—the choice depends on the type of data, CRM capabilities, and reliability requirements.

Table of contents

To transfer requests and orders without loss, you need to define the field composition, matching and resubmission rules in advance, and then test the "contact form → lead" and "WooCommerce order → deal" scenarios. This guide will cover integration options, exchange setup, log access, security, and testing, taking into account your theme, plugins, and WordPress version.

How the integration relates to the theme, plugins and REST API is shown in Review of custom WordPress development. Data exchange with CRM is discussed here.

What data needs to be transferred to CRM?

What data from WordPress should be transferred to CRM?

Before setting up the integration, determine which fields a manager needs to process a request or order. Don't automatically transfer all the information from WordPress: create a data map, mapping each site field to a specific CRM field.

Forms and applications

For the "contact form → lead" scenario, a name, phone number or email address, the text of the request, and the source of the request are usually sufficient. If you have multiple forms on your website, add an identifier or a descriptive name for each form: for example, "Request a Consultation" or "Quotation.".

It is useful to transmit the following data:

name and contact details of the visitor;
message text, selected service or subject of the request;
URL of the page from which the form was submitted;
date and time of dispatch with indication of time zone;
page language, if the site is multilingual;
UTM tags and other agreed traffic source;
Internal application identifier for duplicate search.

Decide in advance which fields are required. For example, a form might require a phone number but not an email address. For Ukrainian numbers, it's best to store the normalized value with the country code separately from the formatted display. This simplifies contact matching, but the normalization rules depend on your CRM.

If the standard connector does not support custom form fields, you may need to WordPress website development. Before you begin, prepare a mapping table: "form field - CRM field - format - required." This will prevent the developer from having to determine business logic based on field names.

WooCommerce Orders

In the "WooCommerce order → deal" scenario, a single customer card isn't enough. The CRM must receive information that allows the manager to understand the purchase contents, amount, and fulfillment method. Therefore, WooCommerce integration with CRM typically covers customer, order, and product data.

order number and internal identifier;
buyer's name, telephone number and email;
shipping address and billing address, if different;
products, variations, SKU, quantity and price of the item;
discounts, coupons, shipping, taxes and total amount;
order currency, for example UAH;
selected payment and delivery methods;
order status and buyer's comment;
order source and registered user ID, if any.

Don't combine the product price, shipping, and discount into a single, unspecified value. Managers and accounting systems may require separate amounts. For variable products, provide not only the product name but also the selected attributes, such as size, color, or configuration.

Also, define a key for connecting the systems. Typically, an immutable internal WordPress or WooCommerce identifier is used for orders, while the display number is stored separately. For the client, the key can be a standardized phone number, email, or their own ID, but the choice depends on the duplicate detection rules of the specific CRM. This field map is the foundation; without it, WordPress integration with the CRM risks creating incomplete records and duplicate transactions.

Select the integration method

Choosing between a connector, webhook, or API

To transmit requests and orders, you can use a ready-made connector, webhook, REST API, or an intermediary service. Choose based not only on ease of setup but also on support for your CRM, resend mechanism, access to logs, and total cost of ownership.

Ready-made connector

A ready-made plugin or module is suitable if it supports the required CRM and data source: a contact form, WordPress, or WooCommerce. This is usually the simplest option for a typical "form → lead" or "order → deal" scenario.

Before choosing, check compatibility with current versions of WordPress, WooCommerce, your theme, and form plugins. The presence of a connector alone does not guarantee the transfer of custom fields, product variations, shipping methods, discounts, and order status changes.

Check whether the module maintains a communication log, displays CRM responses, and can retry sending after a temporary error. If updates are released irregularly or the documentation doesn't describe the data structure, skimping on launch may lead to additional maintenance costs.

Webhook or REST API

A webhook sends data when an event occurs, such as submitting a form or creating an order. It's convenient for quick, one-way data transfers. However, authorization, error handling, retries, and duplicate protection must be considered.

WordPress API Integration Provides more control: a site or a separate module can create and update posts, query statuses, and synchronize directories. The WordPress REST API also allows external systems to access site data through structured HTTP requests, provided the necessary entities and access rights are available.

For complex WooCommerce CRM integration An API is usually preferable when a two-way exchange is required: transferring an order to a CRM and then returning the processing status to the website. This approach requires development, monitoring, and support when changing the API of one of the systems.

Way	Advantages	Restrictions	When it suits
Ready-made connector	Quick launch, interface-based configuration, less custom code	Dependency on plugin features and updates	WooCommerce Standard Forms and Orders
Webhook	Immediate post-event transmission, relatively simple architecture	Replays, logs, and duplicate protection may require improvement.	One-way sending of an application or order
REST API	Flexible field mapping and two-way exchange	Development, documentation and support are needed	Non-standard logic and status synchronization

Intermediate service

The intermediary platform receives events from WordPress, transforms the data, and sends it to the CRM. This option is useful if there is no direct connector or if you need to integrate multiple forms, stores, and systems without having to develop each connection separately.

Consider transaction limits, accessibility of run history, retry times after failures, and the ability to export logs. Consider not only the service fee but also the time required to configure scripts, check for errors, and support changed fields. If request flow is critical to your business, determine what will happen if the CRM is unavailable: will the service retain queued data and can a retransmission be safely initiated?.

Set up data exchange rules

Field mapping, data validation, and duplicate elimination

Before connecting, determine not only the list of transferred data but also the rules for its transformation. Record which WordPress field corresponds to which CRM field, when a new entity is created, and what happens when a resubmission occurs. This scheme reduces the risk of lost requests, duplicates, and incorrect statuses.

Fields and statuses

For the "contact form → lead" scenario, the name, phone number or email, the message body, the submission page, and the user's consent are usually sufficient. It's also useful to transmit the form's technical ID and UTM parameters if they are collected legitimately and are truly needed by managers.

Set rules for optional values in advance. For example, if a visitor doesn't provide a name, don't substitute a dummy one: use an empty value or a neutral label allowed by the CRM. Consistently format the phone number, but keep the original value in the call log if needed for diagnostic purposes.

In the WooCommerce order → deal scenario, map at least:

order number and internal ID;
buyer's contact information;
products, quantities, articles and variations;
cost of items, discount, delivery and total;
payment and delivery method;
customer comment;
currency and order status.

Don't assume that status names are the same. For example, the WooCommerce "processing" status may correspond to a specific transaction stage in the CRM, but this depends on the business process. Create a clear mapping and define the direction of the exchange: from the website to the CRM only or in both directions. When two-way synchronization is used, determine which system is considered the source of truth for payment, shipping, and cancellation.

If you use WordPress API integration, validate data types before sending: pass the amount as a number in the expected format, the date with the specified time zone, and identifiers without arbitrary conversion.

Duplicates and resubmissions

A network failure doesn't always mean the CRM didn't receive the record: the response could have been lost after the lead or deal was created. Therefore, simply repeating the request can result in a duplicate.

Pass a stable external identifier: for a request, this could be the UUID generated when the form was first saved, or for WooCommerce, the order ID along with the site ID. The CRM or middleware should look up the record by this key and update it instead of recreating it. This approach is called idempotency: the same operation, when repeated, does not create new entities.

Set the repetition rules in advance:

retry sending if temporarily unavailable or there is a server error;
increase the interval between attempts and limit their number;
Do not repeat the request without correction if there is a validation error or if you do not have permission;
save the time, operation ID, response code and error reason;
After exhausting the attempts, move the entry to the manual verification queue.

WooCommerce integration with CRM should also distinguish between order creation and subsequent changes. Don't re-submit the entire transaction as a new one when the status changes: use an external ID and a separate update operation. For contact forms, don't rely solely on phone number or email address—these details may be the same for multiple requests. Separate the decision to merge contacts from the uniqueness of each request.

Check security and consent

User consent and data protection when transferring to CRM

Before launching the integration, restrict access to your CRM and WordPress, protect confidential information, and define the legal basis for processing personal data. Don't transfer fields to your CRM "just in case": the data must be relevant for the intended purpose—processing an application, placing an order, or supporting a customer.

Access rights and secrets

Create a separate CRM account for integration with the minimum necessary permissions. For example, if a script only needs to create leads, it doesn't need access to export the entire customer base, financial reports, or deal deletion. This approach reduces the impact of a key leak.

REST API tokens, passwords, and secrets for webhook verification should not be placed in JavaScript, HTML forms, or a public repository. Store them on the server—in a secure configuration or secrets management tool. Restrict access to configuration files and do not output secrets to error logs.

Use HTTPS for WordPress, CRM, and intermediary services;
Check the webhook signature if the sender and CRM support this mechanism;
Set minimal account rights and change keys periodically;
Restrict access to logs, as they may contain phone numbers, emails, and application content;
mask personal data and exclude tokens from logs;
Update WordPress, theme, and plugins after checking compatibility.

At your own WordPress API integration Validate the type, length, and format of input values, and use escaping before outputting them in the admin panel. Also, check user permissions and request security according to WordPress mechanisms. Implement code changes first on staging copies, after creating a backup. Compatibility cannot be guaranteed without checking the WordPress version, theme, form plugins, and WooCommerce.

Personal data

Determine what data your CRM really needs. For a callback, a name, phone number, and the context of the request are usually sufficient. When placing an order, recipient contact information, order details, delivery address, and payment IDs may be required, but full bank card details are not.

Provide a clear notice next to the form: who is receiving the data, for what purpose, how long it is stored, and with whom it may be shared. A link to the privacy policy should be available before submitting the form. Avoid using a pre-checked checkbox where processing is based specifically on consent.

However, consent is not the only possible legal basis. For example, order data may be processed to fulfill a contract, while a separate marketing campaign typically requires an independent assessment of the basis and a separate user choice. Consider Ukrainian data protection laws. GDPR requirements may also apply, particularly if you offer goods or services to people in the EU or track their behavior; it's best to assess the specific applicability with a lawyer.

Record retention periods, deletion procedures, and record correction procedures. If data passes through an external connector, determine the location of its servers, whether it stores request contents, and how backups are deleted. For WooCommerce integration with a CRM, check separately to ensure that personal data isn't being duplicated without the need for WordPress, the CRM, logs, or an intermediary service.

Testing and support

Before launching, test the integration on a staging site and create a backup. Your goal is to confirm not only that the application or order was successfully submitted, but also that errors, retries, and status changes are handled correctly. Compatibility cannot be guaranteed without checking the WordPress version, theme, form plugins, WooCommerce, and CRM settings.

Error scenarios

Run tests for two main sequences: "contact form → lead" and "WooCommerce order → deal." Use separate test contacts so you can find and remove them without affecting your live data.

Test Application Checklist:

Fill in all required fields with correct data and ensure that the lead appears in the correct funnel.
Check the matching of name, phone number, email, source, comment, and UTM tags.
Please enter your Ukrainian number in various accepted formats, including the +380 code.
Submit the form without the required field and make sure that the incorrect record has not been entered into the CRM.
Please resubmit the same data and check the duplicate handling rule.
Temporarily specify an invalid token or test an unavailable API address, then check if the error is fixed.
Reconnect and see if the automatic resend will occur.

For WooCommerce, additionally create a test order with several products, discounts, shipping, and different payment methods. Verify the SKU, quantity, price, currency, total, customer details, and status. If the order is modified or canceled, the CRM should process the event according to a predefined rule, rather than creating another transaction.

Pay special attention to timeouts and repeated webhook requests. Without a request or order ID, a repeat request can create a duplicate. Idempotency is commonly used for protection: the CRM or intermediate handler remembers the external ID and updates the existing record instead of creating a new one.

Synchronization Monitoring

Once WordPress is launched, CRM integration requires regular monitoring. A single "success" message in the form interface isn't enough: it may only indicate that the data is saved on the site, not received by the CRM.

Create a log that includes the event date and time, object type, external ID, destination address, response code, number of attempts, and a brief error description. Do not record tokens, passwords, or full payment or personal information in public logs.

For webhooks and REST APIs, configure a limited number of retries with increasing intervals. Once the retries are exhausted, the event should be queued for manual review, and the responsible party should receive a notification. In WordPress API integration, it's also useful to monitor token expiration, request rate limits, and response format changes.

Periodically compare the number of submitted forms and orders with the number of created objects in the CRM. For WooCommerce integration with the CRM, separately monitor for discrepancies in amounts and statuses. After updating WordPress, WooCommerce, forms, connectors, or PHP, repeat a reduced set of tests on staging. Store descriptions of fields, duplicate rules, and recovery procedures: this reduces diagnostic time if synchronization fails.

Official documentation: WordPress REST API And request authorization.