Amazon, Shopify and Temu Inventory: 12 Data-Governance Questions Before Integration

Connecting Amazon, Shopify, Temu and a warehouse management system is not only an API project. In many cases, the more difficult issue is agreeing on how inventory, orders, returns and exceptions should be defined and managed.

Before building webhooks, middleware or system connections, brands should resolve four basic questions:

1. Who owns the master SKU catalogue?
2. Which system is the authoritative source for sellable inventory?
3. How do stock statuses move through the order and returns lifecycle?
4. When should automation stop and require human review?

If these questions are not settled first, an integration may simply distribute inaccurate data more quickly across every sales channel.

A multi-channel integration works best when developers, warehouse teams, marketplace managers and customer-service staff use the same definitions for terms such as “available,” “reserved,” “returned” and “dispatched.”

Why Data Governance Matters Before an API Project

Amazon, Shopify and Temu all depend on accurate product, order and inventory data. The exact performance metrics, dispatch requirements and seller obligations vary by platform, marketplace, region and fulfilment model, so the latest platform rules should always be confirmed before implementation.

In practice, many overselling and fulfilment problems are not caused by broken code. They often result from unresolved operational definitions.

For example:

• One system may treat reserved stock as available;
• A returned product may be added back to sellable inventory before inspection;
• A warehouse may use a different SKU from the marketplace;
• A cancellation may arrive after picking has already started;
• A manual stock adjustment may overwrite a physical count;
• A webhook may fail without triggering a reconciliation process.

When the data model is agreed first, the API integration becomes easier to design, test and maintain.

12 Questions to Answer Before Integrating Amazon, Shopify, Temu and Your WMS

Phase 1: Master SKU and Inventory Authority

1. Who creates, validates and approves the master SKU catalogue?

The business should define one approved SKU standard before connecting the sales channels.

Amazon may use an ASIN, Shopify may use a product handle or variant ID, and Temu may use its own SKU structure. These platform identifiers should be mapped to a controlled internal SKU rather than treated as interchangeable.

The SKU governance process should define who can create a product, who verifies the barcode and attributes, and who approves changes.

2. Which system is the authoritative source for sellable inventory?

Decide whether the ERP, WMS or OMS owns the official Available-to-Sell balance.

The system of record should be clearly documented. Other systems can receive inventory updates, but they should not independently overwrite the authoritative quantity without a defined rule.

Without this decision, the ERP, WMS and marketplace stores may each show a different balance for the same SKU, creating a direct overselling risk.

3. How are inventory statuses defined across platforms?

A single stock number is not sufficient for multi-channel fulfilment.

At a minimum, the business should define separate statuses for:

• Available;
• Reserved;
• Picked;
• Dispatched;
• Returned – Pending Review;
• Quarantined;
• Damaged;
• In Transit;
• Exception.

Each status should have a clear entry condition, exit condition and system owner.

Phase 2: Order Lifecycle and Fulfilment Triggers

4. At what exact milestone is an order released to the warehouse?

The business should define when an order becomes eligible for allocation and fulfilment.

Depending on the channel, this may require confirmation of:

• Payment;
• Fraud screening;
• Customer address;
• Product availability;
• Cancellation window;
• Marketplace order status;
• Shipping-service requirements.

Releasing an order too early can create avoidable cancellations, address corrections or inventory reservations.

5. How are cancellations and address changes handled after order release?

The operating procedure should explain what happens when a customer cancels an order after:

• Stock has been reserved;
• A picking wave has started;
• The item has been packed;
• A shipping label has been created;
• The parcel has been handed to a carrier.

The system should distinguish between an instruction that can still be stopped automatically and one that requires warehouse or customer-service intervention.

6. How are backorders, partial shipments and bundle splits synchronized?

A multi-channel system needs a defined approach to:

• Backorders;
• Partial shipments;
• Split orders;
• Bundles and kits;
• Parent-child SKUs;
• Partial tracking information.

Each sales channel should receive a status that accurately reflects what has shipped, what remains outstanding and whether the customer should receive a revised delivery update.

7. Who creates the shipping label, and when is it locked?

The responsible system should be defined for each channel.

The process may differ between Amazon seller-fulfilled orders, Shopify merchant-fulfilled orders and Temu orders. The business should document:

• Who generates the label;
• Which system receives the label data;
• When the label becomes final;
• How weight and dimensions are confirmed;
• How label changes are handled;
• How dispatch deadlines are monitored.

The exact requirements should be checked against the current policy and fulfilment model of each platform.

8. What is the returns and reverse-logistics process?

Returned parcels should not automatically be added back to sellable stock.

They should first enter a controlled status such as:

Returned – Pending Review

After physical inspection, the item can be assigned to an appropriate disposition, such as:

• Available for resale;
• Requires repacking;
• Requires repair;
• Quarantined;
• Damaged;
• Returned to supplier;
• Written off.

This process prevents products from being sold again before their condition has been confirmed.

Phase 3: Exceptions, Security and Auditability

9. Which exceptions require photos or brand approval?

The warehouse SOP should define when staff can continue processing and when they must stop and escalate.

Common triggers include:

• Unreadable barcodes;
• Damaged packaging;
• SKU mismatch;
• Missing components;
• Incorrect quantity;
• Suspected counterfeit goods;
• Product-condition concerns;
• Missing or conflicting order information.

The system should record the evidence, decision and person responsible for the resolution.

10. How are system permissions divided?

Read, write and edit permissions should be assigned according to role.

For example:

• Warehouse users may update physical handling statuses;
• Marketplace managers may manage product listings;
• Finance users may review order and settlement information;
• Developers may manage integration credentials;
• Only authorised users may adjust stock quantities manually.

This reduces the risk of an unauthorised user or third-party plugin overwriting the physical inventory balance.

11. What happens when an API or webhook fails?

Before launch, define a fallback process for:

• API rate limits;
• Failed webhooks;
• Sync timeouts;
• Duplicate messages;
• Missing tracking numbers;
• Delayed inventory updates;
• Partial system outages.

The process should specify:

• How many times an automated retry will run;
• When an alert will be triggered;
• Who receives the alert;
• When manual reconciliation begins;
• How the final correction is recorded.

A reliable integration is not one that never fails. It is one that can detect, contain and reconcile failures.

12. How are audit logs and data retention managed?

Every manual stock adjustment, status override and data correction should be traceable to a user ID, system ID or integration event.

Audit controls help the business:

• Investigate inventory disputes;
• Explain marketplace discrepancies;
• Review customer-service cases;
• Identify repeated process failures;
• Confirm who approved a manual change;
• Reconstruct what happened during an outage.

The retention period and access rights for these records should be defined before the integration goes live.

A Shared Inventory Status Glossary

Misaligned terminology is often the starting point for data errors. The following glossary can help developers, warehouse operators and commercial teams use the same definitions.

Status	Meaning	What it does not mean
Available	Physically in stock, not reserved and eligible for allocation	Total physical stock before reservations
Reserved	Allocated to a confirmed order awaiting fulfilment	Already picked or dispatched
Picked	Removed from storage and staged for packing	Already handed to the carrier
Dispatched	Labelled, manifested and handed to the carrier	Guaranteed final delivery
Returned – Pending Review	Returned to the warehouse and awaiting inspection	Ready for resale
Quarantined	Isolated while a product, document or condition issue is reviewed	Automatically unavailable forever
Damaged	Not currently suitable for normal sale or fulfilment	A normal sellable unit
Exception	Held because of an address, stock, SKU, data or channel issue	A delay that can be ignored

What Is Different About Amazon, Shopify and Temu?

Amazon Seller-Fulfilled Orders

Amazon seller-fulfilled operations usually require close monitoring of shipment timing, cancellations, tracking and seller-performance metrics. Brands should maintain an agreed safety-stock policy for high-volume listings, while ensuring that the buffer is visible in the inventory model rather than added informally by different teams.

Shopify DTC Orders

Shopify stores may experience sudden demand changes during promotions, as well as customer-initiated address or order changes.

Some brands use a configurable order-hold period before warehouse release to absorb last-minute changes. The appropriate period depends on payment status, fraud review, warehouse cut-off times and customer expectations.

Temu Orders

Temu fulfilment requirements may vary according to the selected fulfilment model, market and current platform policy. Brands should confirm the applicable dispatch window, label format, tracking requirements and inventory responsibilities before integration.

The important point is not to assume that one channel’s order or inventory workflow can be copied directly to another.

Five Inputs to Prepare Before a WMS or API Review

Before a technical feasibility review, prepare:

Input	What to include
Sales channels	Active platforms, regions, stores and fulfilment models
Master catalogue	Active SKU count, parent-child variants and barcode standards
Order volumes	Average daily orders, peak periods, bundles and partial shipments
Field-mapping matrix	Order, shipment, tracking and SKU data required by each system
Exception SOPs	Procedures for damaged products, missing stock, returns and SKU mismatches

This information helps the integration team assess data structures, workflow ownership and exception handling before recommending a technical solution.

Talk to U-Freight Before You Build

An API connection can move data quickly, but it cannot decide which system owns inventory or what “available” means.

Before investing in middleware or custom development, share your current sales channels, SKU structure, order volumes, warehouse workflow and exception procedures with the U-Freight team.

U-Freight can help review the operational alignment between your sales channels, warehouse processes and inventory data before technical integration begins. You can also review the wider U-Freight eCommerce fulfilment solutions to understand the warehouse and order-processing context.

Request a data-governance feasibility review before building the integration.

常見問題