User Guide for Two-Way Multi Store Product & Inventory Sync

Synchronize Products, Orders, Inventory, Customers & Store Data Across WooCommerce Sites

Two-Way Multi Store Product & Inventory Sync for WooCommerce helps store owners connect and synchronize multiple WooCommerce stores from one central HUB.

Use it to synchronize:

• Products and variations
• Inventory and stock
• Product prices
• Categories, tags and brands
• Product attributes
• Featured and gallery images
• Orders
• Customers
• Coupons
• Shipping classes
• Supported WooCommerce metadata

The plugin supports HUB → Node, Node → HUB, and bi-directional WooCommerce synchronization.

WordPress Multisite is not required. Connected stores can be completely independent WooCommerce installations running on separate domains or servers.

1. Requirements

Before getting started, make sure your stores meet the following requirements:

• WordPress 6.5+ recommended
• WooCommerce 8.0+ recommended
• PHP 8.0+
• HTTPS recommended
• WooCommerce REST API available
• Valid Read/Write WooCommerce REST API credentials
• WordPress Cron or server cron functioning
• Action Scheduler working correctly on the HUB

For advanced direct media uploads, a WordPress Application Password may also be configured.

2. Installation

Install the plugin only on the WooCommerce store you want to use as the HUB.

Steps

1. Log in to the HUB WordPress dashboard.
2. Go to Plugins → Add Plugin.
3. Click Upload Plugin.
4. Select the plugin ZIP file.
5. Click Install Now.
6. Activate the plugin.

After activation, open:

WooCommerce → Store Sync

3. Understanding HUB and Node Stores

The HUB is the WooCommerce store where the synchronization plugin is installed.

Node stores are connected WooCommerce stores.

Example:

                     HUB Store
                 Store Sync Plugin
                       │
          ┌────────────┼────────────┐
          │            │            │
          ▼            ▼            ▼
       Node 1        Node 2        Node 3

The plugin does not normally need to be installed on the Node stores.

Node communication uses:

• WooCommerce REST API
• WooCommerce Webhooks
• WordPress REST API where required
• Incremental polling as an inbound safety mechanism

4. Open Store Sync

Go to:

WooCommerce → Store Sync

The administration interface includes areas for:

• Sites
• Sync Configuration
• Mappings
• Manual Sync
• Queue
• Jobs
• Conflicts
• Logs
• Settings

5. Connect a Node Store

Before synchronization can begin, connect each Node to the HUB.

Create WooCommerce REST API Keys

On the Node store:

1. Go to WooCommerce → Settings → Advanced → REST API.
2. Click Add Key.
3. Enter a description such as HUB Store Sync.
4. Select an administrator or suitable WooCommerce user.
5. Set permissions to Read/Write.
6. Generate the API key.
7. Copy the Consumer Key and Consumer Secret.

Add the Node on the HUB

On the HUB:

1. Open WooCommerce → Store Sync → Sites.
2. Click Add Site.
3. Enter the Node store URL.
4. Enter the Consumer Key.
5. Enter the Consumer Secret.
6. Choose the synchronization direction.
7. Click Test Connection.
8. Save the site.

6. Synchronization Directions

Each connected store can have its own synchronization direction.

Push

HUB → Node

Changes made on the HUB are synchronized to the Node.

Use Push when the HUB is your primary product or store-management system.

Pull

Node → HUB

Changes made on the Node are synchronized back to the HUB.

Bi-Directional

HUB ⇄ Node

Supported changes can travel in both directions.

The plugin uses canonical mappings and synchronization-state protection to prevent changes from continuously bouncing between stores.

7. Inbound Webhook Health

Pull and Bi-Directional connections use WooCommerce webhooks for near-real-time inbound synchronization.

The Sites screen may display:

• Healthy
• Degraded
• Error
• Not Required

Use Repair Inbound if required.

Repair Inbound can:

• verify WooCommerce webhooks;
• recreate missing webhook definitions;
• reactivate supported webhook topics;
• verify inbound delivery configuration;
• run an incremental Node poll.

8. Polling Safety Net

Webhooks are the primary inbound mechanism.

If a webhook is delayed or blocked, the plugin can detect modified Node resources through incremental REST polling.

Example:

Node change
   ↓
Webhook
   ↓
Queue

If webhook delivery is unavailable:

Node change
   ↓
Incremental poll
   ↓
Queue

Previously synchronized states are tracked so the same update is not repeatedly queued.

9. Sync Configuration

Open a connected Node and go to Sync Configuration.

The main entity switches include:

• Products
• Orders
• Customers
• Coupons
• Shipping Classes

Only configuration sections related to enabled entities are displayed.

This keeps the interface focused and easier to configure.

10. Product Sync Configuration

Enable Products to display Product Scope, Product Fields, matching options and media configuration.

WooCommerce product synchronization supports:

• Simple products
• Variable products
• Variations
• Pricing
• Stock
• Taxonomies
• Attributes
• Images
• Supported metadata

11. Product Scope

Choose which products are eligible for synchronization.

Available criteria can include:

• Specific products
• Product type
• Product status
• Publication date
• Stock status
• Minimum/maximum stock quantity
• Minimum/maximum price
• Categories
• Tags
• Brands

Taxonomy filters can optionally include descendant terms.

12. Product Filter Matching

Choose how configured filters should behave.

ANY

A product qualifies when at least one configured filter matches.

Example:

Category = Hair Care
OR
Brand = Example Brand
OR
Stock Status = In Stock

ALL

A product qualifies only when every configured filter matches.

Example:

Category = Hair Care
AND
Brand = Example Brand
AND
Stock Status = In Stock

13. Product Fields

Select which fields are allowed to synchronize.

Supported fields can include:

• Product title
• Slug
• Description
• Short description
• SKU
• GTIN / UPC / EAN / ISBN
• Regular price
• Sale price
• Sale schedule
• Manage stock
• Stock quantity
• Stock status
• Backorders
• Weight
• Dimensions
• Tax status
• Tax class
• Categories
• Tags
• Brands
• Attributes
• Images
• Gallery
• Downloads
• Supported custom meta

If a field is unchecked, the receiving store’s value is left unchanged.

14. Product Matching and Duplicate Prevention

The product resolver uses this identity hierarchy:

1. Persistent canonical mapping
2. Exact SKU
3. Exact GTIN / UPC / EAN / ISBN
4. Exact slug
5. Exact normalized title
6. Create new product

The resolver is designed to prevent unnecessary duplicate WooCommerce products.

15. Persistent Mapping

Once the plugin establishes:

HUB Product #100 ⇄ Node Product #500

that relationship becomes authoritative.

Later changes to SKU, title or other product fields do not cause the products to be treated as unrelated.

16. SKU Matching

If no valid mapping exists, the resolver checks for an exact SKU match.

Before adopting that Node product, the plugin checks whether it is already canonically mapped to another HUB product.

An existing mapping is never silently stolen.

17. GTIN Matching

If SKU does not match, the resolver checks WooCommerce’s global unique identifier.

This can represent:

• GTIN
• UPC
• EAN
• ISBN

Exact matching is required.

18. Slug Matching

If neither SKU nor GTIN identifies the product, the resolver checks the exact product slug.

Slug matching is lower priority because WordPress slugs can change when products are renamed or recreated.

19. Exact Product Title Matching

The final automatic matching method is exact normalized title matching.

The plugin does not use unsafe fuzzy matching for automatic adoption.

If more than one destination product matches the same exact title, synchronization reports an ambiguity rather than guessing.

20. New Product Creation

A new destination product is created only when:

Mapping
SKU
GTIN
Slug
Title

all fail to identify a safe existing product.

The new canonical mapping is saved immediately after creation.

21. Variable Product Sync

Variable WooCommerce products synchronize through the parent product.

Variation data can include:

• Variation SKU
• Price
• Sale price
• Sale dates
• Stock
• Stock status
• Backorders
• Weight
• Dimensions
• Attributes
• Variation image

When a variation causes the sync, the Queue can display:

HUB · Variation ID - 24441 · Parent ID - 24446

This provides better visibility while the parent remains the synchronization unit.

22. Product Images and Galleries

Supported media includes:

• Featured product image
• Product gallery
• Variation images

The plugin attempts to reuse existing destination attachments before uploading a new image.

This helps prevent duplicated files such as:

product.jpg
product-1.jpg
product-1-1.jpg

23. WordPress Application Password for Media

For plugin-free Nodes, a WordPress Application Password can provide more reliable direct media uploads.

On the Node:

1. Go to Users → Profile.
2. Find Application Passwords.
3. Create a new Application Password.
4. Copy the generated value.
5. Enter the username and Application Password in Store Sync.
6. Test media access.

Do not use the normal wp-admin password.

24. Order Sync Configuration

Enable Orders to display the Order Scope and Order-specific settings.

WooCommerce order synchronization supports data such as:

• Status
• Currency
• Customer information
• Billing
• Shipping
• Customer note
• Line items
• Shipping lines
• Fees
• Coupons
• Taxes
• Supported meta

25. Order Scope

Orders can be filtered using:

• Specific Order IDs
• From date
• To date
• Order status
• Billing email
• Billing first name
• Billing last name
• Payment method
• Products contained in the order
• Minimum total
• Maximum total

26. Order Date Filters

Example:

From:
30 July 2026

To:
blank

A blank To date means:

30 July 2026 → current store date

Order dates are queried through WooCommerce’s order APIs for compatibility with both traditional storage and HPOS.

27. Order ANY Filters

ANY means a unique union of all matching criterion sets.

Example:

From 30 July
Status = Processing
Payment Method = COD

ANY means:

Date-range orders
OR
Processing orders
OR
COD orders

An order only needs to match one configured criterion.

28. Order ALL Filters

ALL means every configured criterion must match.

Example:

From 30 July
Status = Processing
Payment Method = COD

The order must be:

inside the date range
AND
Processing
AND
paid by COD

29. Date Range and Total Range

From/To is treated as one date-range criterion:

From <= Order Date <= To

Minimum/Maximum total is also treated as one criterion:

Min <= Order Total <= Max

This provides predictable behavior under both ANY and ALL.

30. HPOS-Compatible Order Sync

The plugin uses WooCommerce order APIs instead of depending only on the legacy WordPress posts table.

This provides compatibility with WooCommerce HPOS.

31. Refund Protection

WooCommerce refunds are not treated as ordinary Orders for regular synchronization.

Refund objects are excluded before the Order Scope evaluator processes them.

32. Historical Order Line Recovery

Old WooCommerce orders may reference products that were:

• deleted;
• recreated;
• imported;
• migrated;
• disconnected from their original order-item IDs.

The plugin attempts to recover historical order lines through:

Product ID
Variation ID
SKU
GTIN
Slug
Exact product title
Variation attributes

If a valid catalog product can be recovered, the product is mapped/synchronized before the Order is sent.

33. Orphaned Historical Order Lines

If an historical line cannot be safely matched to a product, the plugin does not create a fake product.

Instead it reports a permanent diagnostic error.

This protects both catalog and order integrity.

34. Order Status Synchronization

For Bi-Directional connections:

HUB:
On Hold → Processing

can update the mapped Node order.

Likewise:

Node:
Processing → Completed

can update the mapped HUB order.

Order synchronization includes loop protection so the received change is not immediately sent back again.

35. Order Echo Protection

The plugin records synchronization direction and modification state.

Example:

HUB → Node

The resulting Node webhook/poll event is recognized as the state just created by the HUB and is ignored.

A genuine later change on the Node remains eligible for synchronization.

36. Customers

Enable Customers to synchronize WooCommerce customer records.

Manual Customer Sync supports searching by:

• Customer name
• Email
• User ID

Queue labels can look like:

Customer #142 · John Smith · john@example.com

37. Create Customer Before Order

When enabled, the plugin can synchronize a registered customer before creating the corresponding destination order.

This helps preserve WooCommerce Order → Customer relationships.

38. Coupons

Enable Coupons to synchronize WooCommerce coupons.

Manual Coupon Sync supports:

• Coupon code
• Coupon ID
• Specific selection
• All eligible coupons

Example:

Coupon SUMMER20 · #421 · percent 20

39. Shipping Classes

Enable Shipping Classes to synchronize WooCommerce shipping classes.

Search supports:

• Name
• Slug
• Term ID

Example:

Shipping Class Heavy Items · heavy-items · #18

WooCommerce Shipping Classes do not provide a native creation-date field, so the plugin does not invent one.

40. Source Creation Dates

The plugin preserves source creation-date information where supported.

For new entities created locally on the HUB, WooCommerce/WordPress creation dates can be restored when the local CRUD API safely supports them.

For plugin-free Node stores, some WooCommerce REST creation-date properties are read-only.

In those cases, the plugin retains the original source timestamp as protected synchronization provenance.

41. Manual Sync

Manual Sync supports:

• Products
• Orders
• Customers
• Coupons
• Shipping Classes

Only enabled entities are available for execution.

42. Sync Selected Records

Choose individual records using the searchable selector.

Then click the Manual Sync action.

43. Sync All Eligible Records

Leave the record selector empty to synchronize all eligible records up to the Manual Sync safety limit.

Products and Orders still respect their configured scopes.

44. Manual Sync Limit

Manual synchronization has a safety cap to prevent a very large admin request.

A batch may display:

Queued 500 records

If the cap was reached, the interface indicates that this is the maximum queued for that run.

45. Queue

The Queue provides real-time visibility into synchronization activity.

Information includes:

• Resource
• Destination
• State
• Progress
• Attempts
• Result
• Actions

46. Queue States

Typical states include:

• Queued
• Processing
• Retrying
• Completed
• Completed With Errors
• Cancelled
• Failed

47. View Queue Items

Click View Items to inspect the exact jobs included in a batch.

For Orders, item details can include:

• Order ID
• Order date
• Customer
• Total
• Direction
• State
• Attempts
• Result/Error

This is useful when auditing large Manual Sync batches.

48. Background Processing

Synchronization runs through WooCommerce Action Scheduler.

The system supports:

• Background jobs
• Progress tracking
• Retries
• Worker leases
• Heartbeats
• Cancellation
• Permanent-failure handling

49. Worker Heartbeats

Long-running jobs can include:

• Media uploads
• Variable products
• Many variations
• Large REST requests

Worker heartbeats tell the Queue that the current process is still alive.

A slow but healthy job should not be treated as abandoned.

50. Retry Logic

Temporary failures can retry.

Examples:

• Connection timeout
• Rate limit
• Temporary remote server error

Permanent issues should not be endlessly retried.

Examples:

• Mapping conflict
• Duplicate identity
• Orphaned historical order line
• Ambiguous product match

51. Mappings

Mappings connect equivalent entities between stores.

Examples:

HUB Product #100 ⇄ Node Product #500

HUB Variation #101 ⇄ Node Variation #501

HUB Order #200 ⇄ Node Order #900

52. Mapping Ownership Protection

A Node entity cannot safely belong to multiple conflicting HUB entities.

If the destination product is already mapped elsewhere, synchronization stops and reports the conflict.

This prevents silent mapping corruption.

53. Conflicts

The Conflicts section helps identify synchronization conditions that require administrator review.

Examples:

• Duplicate SKU ownership
• Conflicting canonical mappings
• Ambiguous exact title matches
• Missing order-product relationships
• Stale catalog identities

54. Logs

Logs record synchronization activity and errors.

Typical columns include:

• Date
• Level
• Site
• Entity
• Message

55. Common Log Messages

Example inbound Product sync:

Product "Example Product"
updated on HUB from "Node Store".

Example polling event:

Inbound polling safety net detected product update
for Example Product · SKU: ABC · Node #876;
queued job #410.

Example permanent identity error:

Node product #102 is already mapped
to another HUB product.

56. Logs and Filters

Use available filters to narrow logs by:

• Connected Site
• Entity
• Log Level
• Search text

Pagination helps maintain performance on stores with extensive synchronization history.

57. Recommended First-Time Setup

For the safest rollout:

1. Install the plugin on the HUB.
2. Add one Node.
3. Test the REST connection.
4. Configure direction.
5. Enable Products.
6. Select Product Fields.
7. Configure Product Scope.
8. Sync a few test products.
9. Review Mappings.
10. Verify variations and images.
11. Enable Orders.
12. Configure Order Scope.
13. Sync a small Order batch.
14. Review Queue and Logs.
15. Enable Customers, Coupons and Shipping Classes as required.
16. Add more Nodes after validating the first connection.

58. Best Practices

For reliable WooCommerce multisite and multi-store synchronization:

• Use unique SKUs.
• Add GTIN/EAN/UPC values where available.
• Avoid duplicate products with the same SKU.
• Do not delete mappings unless necessary.
• Keep REST credentials active.
• Use HTTPS.
• Monitor Action Scheduler.
• Keep WordPress Cron functioning.
• Test with small batches first.
• Review Queue and Logs during setup.
• Back up stores before large migrations.
• Avoid security rules that block REST API or webhooks.

59. REST API Credential Security

The HUB connects to each Node using WooCommerce REST API credentials with Read/Write permission.

These credentials can access and modify supported WooCommerce data on the connected store, so they should be treated as sensitive access credentials.

Recommended Security Practices

• Create a dedicated WooCommerce REST API key for the synchronization connection.
• Use a dedicated WordPress user with only the permissions required to manage WooCommerce data.
• Do not reuse personal administrator API keys.
• Never share Consumer Keys or Consumer Secrets publicly.
• Use HTTPS on both HUB and Node stores.
• Revoke and regenerate credentials immediately if they are exposed or no longer required.
• Remove API credentials when disconnecting a store permanently.

WooCommerce REST API keys can be managed from:

WooCommerce → Settings → Advanced → REST API

If a connected store should no longer be accessible by the HUB, revoke its API key from this screen.

60. Troubleshooting Synchronization Issues

For synchronization problems, first review:

WooCommerce → Store Sync → Queue

and:

WooCommerce → Store Sync → Logs

These screens normally provide the resource ID, destination, attempts, status, and detailed error message.

60.1 Webhook Failures

If Node changes are not reaching the HUB:

1. Confirm the connection uses Pull or Bi-Directional mode.
2. Check the site’s inbound webhook status.
3. Use Repair Inbound if the status is Degraded or Error.
4. Confirm the Node can reach the HUB webhook endpoint.
5. Check security plugins, firewalls, CDN rules, or hosting restrictions.
6. Review WooCommerce webhook delivery logs on the Node.

The plugin also uses incremental polling as a fallback when supported webhook events are missed.

60.2 REST API Authentication Errors

Errors such as 401, 403, or authentication failures usually indicate invalid credentials or blocked REST access.

Check that:

• the Consumer Key and Consumer Secret are correct;
• the API key has Read/Write permission;
• the associated WordPress user still exists;
• HTTPS is working correctly;
• security plugins are not blocking WooCommerce REST requests;
• the Node REST API is accessible.

If necessary, generate a new dedicated API key and update the connection.

60.3 Action Scheduler or Cron Issues

Synchronization jobs depend on WooCommerce Action Scheduler and WordPress/server cron.

If jobs remain Queued or Processing for an unusually long time:

1. Open WooCommerce → Status → Scheduled Actions.
2. Check for failed or overdue actions.
3. Confirm WordPress Cron is running.
4. Check whether the hosting provider disables WP-Cron.
5. Review PHP/server error logs.
6. Verify sufficient PHP memory and execution resources are available.

For large stores, a real server cron is recommended for more reliable background processing.

60.4 Failed Jobs and Retries

Temporary failures may retry automatically.

Examples include:

• network timeout;
• temporary remote server error;
• rate limiting;
• temporary connection failure.

Permanent data or identity problems should stop instead of retrying repeatedly.

Examples include:

• canonical mapping conflict;
• duplicate SKU ownership;
• ambiguous product identity;
• missing historical order-product relationship.

Use Queue → View Items and Logs to identify the exact failed resource.

60.5 Mapping Problems

Mappings define the relationship between HUB and Node entities.

Example:

HUB Product #100 ⇄ Node Product #500

If a mapping conflict occurs:

1. Compare the HUB and Node product.
2. Check SKU, GTIN, slug, title, and variation information.
3. Confirm the Node product is not already mapped to another HUB product.
4. Correct duplicate or stale catalog data before retrying.

Do not remove mappings unless you have confirmed that the existing relationship is incorrect.

60.6 Conflict Resolution

The plugin intentionally stops when it cannot safely determine product identity.

Typical conflicts include:

• duplicate SKU;
• duplicate GTIN;
• existing canonical ownership;
• ambiguous slug or title;
• multiple possible product matches.

Resolve the underlying catalog conflict first, then retry synchronization.

The resolver follows:

Canonical Mapping → SKU → GTIN → Slug → Exact Normalized Title → Create New

Deletion propagation always requires an established canonical mapping and does not rely on SKU, GTIN, slug, or title matching.

60.7 Recommended Information When Requesting Support

When reporting a synchronization issue, include:

• plugin version;
• WooCommerce versions on HUB and Node;
• synchronization direction;
• entity type;
• HUB ID;
• Node ID, if available;
• Queue result;
• relevant Log message;
• REST/API error code, if shown.

This information helps identify synchronization issues significantly faster.