Before connecting WordPress to a CRM, decide who owns each field

Make “sync the customer” more specific

Imagine a website sends a new inquiry to a CRM. Later, a staff member corrects the contact's company name in the CRM. The visitor submits another form with the old company name. Should that new submission overwrite the correction?

This is an illustrative planning question, but it exposes a real design decision. Sending data between two systems is not the same as deciding which values should win. A short field-ownership plan makes that decision visible before code or plugin settings make it for you.

Write one row for each important field

List the fields the workflow genuinely needs. For each one, identify its source, destination, allowed direction and update rule. Avoid copying everything simply because the API makes it available.

For an inquiry workflow, the original message might be a record of what the visitor submitted, while a staff-maintained status belongs to the CRM. An order number might travel from the store to the CRM as a reference without becoming editable in both places. These are example decisions; the right ownership follows your business process.

• Field: the exact piece of information and what it means.
• Owner: the system or person allowed to make the authoritative change.
• Direction: one-way transfer, a lookup, or a carefully defined update in both systems.
• Update rule: create only, replace a blank value, or update under a stated condition.
• Exception: what happens when the value is missing, invalid or disputed.

Choose a durable way to match records

Decide how the integration recognizes the same record on a later update. A display name is usually a poor choice because names can change or be shared. Depending on the systems, a stored source-record identifier can give the connection a stable reference.

Write down what happens when no match exists and what happens when there is more than one possible match. A manual review state can be more useful than silently creating another contact or overwriting the wrong one. This is an implementation recommendation, not a rule imposed by WordPress.

Separate the event from the work it triggers

WooCommerce webhooks notify a chosen URL when an event occurs, such as an order or product change. They are useful for starting a workflow, but the receiving integration still needs rules for what to do with that event.

Plan what happens if the same update is processed again, if the destination is temporarily unavailable, or if a later correction arrives. For example, an update can refer back to an existing record instead of creating a new one every time. The exact retry and duplicate-handling rules depend on the system.

WooCommerce records webhook delivery logs and can disable a webhook after repeated delivery failures. Someone therefore needs a way to notice a stopped connection and decide what should be replayed. A delivery response by itself should not be confused with confirmation that every downstream business step finished.

Give the connection the access its task needs

WooCommerce API keys are tied to a WordPress user and can be assigned read, write or read/write permissions. Choose access to match the workflow. A reporting connection that only retrieves data has different needs from one that updates store records.

For the WordPress REST API, the official authentication guide documents application passwords over HTTPS for supported authenticated requests. Authentication depends on the API you are using; a WordPress application password and a WooCommerce consumer key are different credentials.

Keep those credentials in server or service configuration rather than frontend scripts, page content or an ordinary project brief. Agree who maintains the connection and how access is removed when it is no longer needed.

Test the decisions with a few example records

Before rollout, walk through a new record, an existing record, a changed email address, a missing field and a failed destination request. Check the resulting records as well as the request logs. Those examples will often reveal an unclear ownership rule faster than a longer technical specification.

Once the workflow is explicit, choosing between an existing plugin, an automation platform and custom code becomes easier. You can judge each option against the behavior your team actually needs.

Related reading

• API integration services
• WordPress and agency support