How to Integrate your e-Commerce Site with your WMS:How to Integrate your e-Commerce Site with your WMS

The two platforms will typically each provide at least one integration option for exchanging data with third party systems. If both are well-established platforms then there’s a good chance that an existing solution is available for linking the two. For example our own OrderFlow WMS platform supports e-commerce integration with Amazon, eBay, Magento, Shopify, WooCommerce and Spree without requiring any bespoke development.

If an interface already exists between your two platforms it’s important to understand what it offers and to make sure it’s able to deliver all the functionality you require. If a solution doesn’t exist you will need to develop one yourself or have someone else do it for you.

Bear in mind that several of the most popular hosted e-commerce platforms impose API call limits that may require you to throttle the rate at which you can exchange data. Your design should allow for this, usually by prioritising inventory updates. As an example, if the API limits calls to two every second and you despatch 5,000 orders a day it will take the WMS more than 40 minutes to push the despatch notifications to the eCommerce platform when your courier collects every evening. Unless you lower the priority of the despatch updates you may find you’re unable to receive any new orders for forty minutes.

This doesn’t matter a great deal if you’re only selling on one sales channel. However, it can be a major problem if you sell on multiple channels – delays in receiving new orders or updating the stock position on all the channels in a timely manner will cause them to oversell.

It’s also important to be aware that many integration options that might be suitable for small sites don’t scale well. Simple interfaces that allow the WMS to pull an entire product catalogue every night are fine if you need to support a couple of hundred stock keeping units (SKUs), but will be unworkable if you try to pull the details for twenty thousand SKUs in a single request. The situation improves a little if the API allows you to request ‘x’ number of SKUs at a time, which is known as API pagination, but the best approach is to use an API solution that allows you to pull just those products that have been created or updated since the last pull.

If messages aren’t acknowledged by the receiving system the problem should be made visible to the appropriate users within the originating system. The integration design should be able to distinguish between application level errors and connectivity errors so that system resource isn’t wasted trying to resend messages that the receiving system has explicitly rejected. Instead the error should trigger whatever processes are needed to resolve the problem.

It is important to design the integration to allow for the possibility that either of the systems or the network connectivity between them may occasionally be unavailable. This should be immediately visible to the system administrators, but the two systems should automatically catch-up with one another when connectivity is reestablished.

A sensible approach to retrying failed messages is also important. If the e-commerce environment is taken offline for maintenance the WMS should not generate thousands of message retries that will flood the interface as soon as connectivity is reestablished.

The technical team that look at the requirement from a warehousing perspective will be used to the concept of SKUs – these are the uniquely identified items that correspond with physical stock. However this is not always the case for e-commerce platforms where it’s often possible to create a ‘parent’ product definition and then define different colour and size variants. The integration you put in place needs to be able to distinguish between physical SKUs that you can drop on your foot and logical ones that don’t physically exist, as the WMS platform is only interested in physical SKUs. 

WMS platforms generally assume that product SKU codes and product barcodes are unique to a particular product and the platform is usually designed to ensure duplicate values cannot be used for multiple products. This may not be the case in e-commerce platforms where it’s often possible to create multiple products with the same SKU or barcode values. It’s well worth running a few database queries to check your assumptions about the e-commerce database values before finalising your design.

If you work in a sector where product ranges change quickly, it may be that only a small proportion of the product catalogue defined in the e-commerce platform is actually active. It’s worth considering whether old product definitions that will never be of interest to the WMS can be excluded and what mechanism can be used in future to retired old SKUs once they are discontinued.

The basic dataflows that form a part of most e-commerce platform and WMS integrations are:

• Sync the product catalogue
• Allow the WMS to receive orders from the sales channel
• Allow the sales channel to receive inventory levels from the WMS
• Allow the sales channel to receive order updates from the WMS

The product catalogue is generally pulled into the WMS from either the primary e-commerce platform or the merchandising platform where new products are first defined. If the product is going to be sold on multiple sales channels it’s important to understand how the SKUs will be uniquely identified across all environments. The WMS will usually only require a small subset of the product data available.

Customer orders will be pulled from one or more e-commerce platforms, usually when the payment has been authorised. It should not be necessary for the WMS to receive any payment details beyond what is required to be printed on the customer paperwork that is despatched with the order.

The inventory level will be pushed to the e-commerce platform whenever stock levels change. The figure that is most relevant is the ‘available stock’ quantity, which is the unallocated stock available to fulfil future orders. It is typically the e-commerce platform that decides whether to take a product off sale or change the customer’s expectation about lead times, the WMS simply pushes a stock quantity.

In multi-channel environments the WMS might be configured to push an available stock figure of zero to some channels before the product is actually out of stock. This approach can prevent overselling when working with sales platforms that impose a delay on API data transfers.  (see Time lags and performance considerations section above).

The WMS will push back order updates to the relevant e-commerce environment. The most important update is usually the despatch confirmation, which will contain the courier service used and any available tracking reference. Other intermediate order updates might also be generated but it’s often not clear how these should be mapped to the different order states supported within the e-commerce environment.

The e-commerce platform should be responsible for pushing despatch notification emails to your customers. This ensures they are in the same format as the original order confirmation email and reduces the number that will be wrongly identified as spam.

If the WMS needs to support split shipments the updates will need to contain information about the line items and quantities despatched in each shipment rather than just confirming that the order has been processed. The e-commerce environment will then need to create multiple despatches against the original order and push appropriate email updates to the customer for every despatch.

More complete e-commerce integration might include some or all of the following elements; cancellations, RMAs, return confirmations, stock levels for composite products, payment requests and order modifications.

Purchase order integration that links with the systems that place orders on suppliers can also offer significant benefits, particularly because it can provide the warehouse with a view of what stock is expected and can allow more efficient goods-inward processes to be supported.

Both areas are beyond the scope of this article but should follow the same general rules that are outlined above.