Connecting inventory software to an online store

Connecting an inventory tool to an online store starts with business rules. The integration needs to know which system owns each field, how products match and what an available quantity represents.

Write these decisions down before selecting endpoints or scheduling imports. Otherwise, the connection can faithfully copy numbers that mean different things in the two systems.

Define stock and field ownership

Physical quantity, reserved quantity and quantity available for sale may differ. Agree how pending orders, cancellations, returns and damaged goods affect each figure.

Consider a product with five units on the shelf and two reserved for unpaid orders. The website might be allowed to sell three, but that depends on the reservation policy and whether those orders will expire. There is no useful synchronisation rule until that policy is explicit.

Assign an owner to each field. Inventory software might own stock, while the website owns descriptions and images. Prices may follow another process. Avoid allowing both systems to overwrite the same value without an agreed priority.

Match products and variations

Choose a stable internal reference, such as a unique SKU. Check for duplicate and missing values before connecting the systems. A variation with its own stock needs a separate identity.

When the systems use different identifiers, keep a mapping table rather than guessing from names. Unmatched records should appear in an exception list with enough information for staff to resolve them.

For WooCommerce, review the REST API product model, including stock management, quantities, availability and backorder settings. Mapping a single quantity while ignoring those settings can produce an incomplete result.

Choose update timing

Separate the initial import from ongoing updates. Descriptions may tolerate a scheduled batch, while sales and stock adjustments can require a faster path.

Event-driven updates can handle immediate changes. A scheduled reconciliation can compare the agreed fields and detect missed events. Define how an older event should behave if it arrives after a newer adjustment.

A receiver should record an event before reporting that it has accepted it. Where delivery can repeat, use stable operation identifiers or another duplicate-handling mechanism. A repeated message must not reduce stock twice.

Design for failed delivery

Networks fail, credentials expire and products can be deleted between requests. Record the affected identifier, operation, time and error without unnecessarily logging customer details or secrets.

Retry temporary failures with a controlled delay. Put permanently invalid records into a review queue rather than retrying indefinitely.

WooCommerce exposes webhook status and delivery logs. Delivery failures can disable a webhook, so a successful setup test does not establish that it will keep delivering. Monitor recent activity and failures.

Test a complete product lifecycle

Start with a small product group. Follow a purchase, reservation expiry, cancellation, refund and manual stock adjustment through both systems, according to the chosen rules.

The operational view should show the latest successful update, pending work, failed records and unmatched products. Give someone responsibility for those exceptions and a controlled way to retry a corrected record.