Multi-Channel Selling

Đồng bộ tồn kho Amazon, eBay và Walmart qua API

Tìm hiểu cách đồng bộ tồn kho giữa Amazon, eBay và Walmart: API ghi dữ liệu, giới hạn theo lô, chống bán vượt tồn và kiểm tra sai lệch.

Ảnh đại diện Long Nguyen

Long Nguyen

Lập trình viên Fullstack · Kỹ sư AI · Nhà nghiên cứu

• • 5 phút đọc •

Một sổ tồn kho, ba luồng ghi dữ liệu

Sơ đồ sổ tồn kho trung tâm gửi số lượng đã đệm đến các adapter của Amazon, eBay và Walmart, đồng thời có bộ đối soát đọc lại tồn kho thực tế để phát hiện sai lệch

Câu trả lời ngắn gọn là: hãy duy trì một con số tồn kho duy nhất trong hệ thống do bạn kiểm soát, rồi đẩy con số đó đến từng sàn thông qua API ghi dữ liệu riêng. Amazon, eBay và Walmart không trao đổi dữ liệu trực tiếp với nhau, và không nền tảng nào báo cho bạn biết khi một kênh khác vừa bán nốt sản phẩm cuối cùng. Việc đồng bộ là trách nhiệm của bạn.

Điều này khó hơn tưởng tượng vì ba API gần như khác nhau ở mọi khía cạnh: cách xác định số lượng, số mặt hàng tối đa trong một lần gọi và ý nghĩa thực sự của phản hồi thành công. Hướng dẫn này trình bày trước luồng ghi dữ liệu của từng kênh, sau đó là các nguyên tắc thiết kế giúp số liệu luôn chính xác. Các thông tin dưới đây đã được đối chiếu với tài liệu dành cho nhà phát triển của các nền tảng vào ngày .

Kiến trúc bền vững gồm một sổ tồn kho và một adapter mỏng cho mỗi kênh:

  • Sổ tồn kho: lượng hàng hiện có trừ đi số lượng đã giữ cho các đơn hàng đang mở trên mọi kênh.
  • Lớp quy tắc: các mức đệm và giới hạn riêng cho từng kênh, dùng để chuyển số tồn kho thành số lượng có thể bán.
  • Adapter: chuyển số lượng có thể bán thành lệnh gọi đến Amazon, eBay hoặc Walmart, đồng thời ghi nhận số lượng mỗi kênh đã chấp nhận.
  • Bộ đối soát: đọc lại số lượng thực tế từ từng kênh và đánh dấu các sai lệch.

Cách cập nhật tồn kho Amazon bằng SP-API

Amazon cung cấp hai luồng ghi dữ liệu. Listings Items API cập nhật từng listing, còn khi cần xử lý hàng loạt, hướng dẫn Listings Items API của Amazon trỏ đến loại feed JSON_LISTINGS_FEED trong Feeds API, sử dụng cùng các schema. Ứng dụng của bạn cần có vai trò Inventory và Order Tracking hoặc Product Listing cho cả hai phương thức.

Số lượng của một offer do người bán tự hoàn tất đơn được lưu trong thuộc tính fulfillment_availability, với mã kênh DEFAULT. Một request có dạng như sau (ATVPDKIKX0DER là marketplace ID của Mỹ; hãy dùng product type thực tế của listing, vì PRODUCT chỉ là giá trị dự phòng cho những loại mà API chưa hỗ trợ đầy đủ):

PATCH /listings/2021-08-01/items/{sellerId}/{sku}?marketplaceIds=ATVPDKIKX0DER
{
  "productType": "PRODUCT",
  "patches": [
    {
      "op": "replace",
      "path": "/attributes/fulfillment_availability",
      "value": [
        { "fulfillment_channel_code": "DEFAULT", "quantity": 12 }
      ]
    }
  ]
}

Bốn đặc điểm của Amazon dễ làm hỏng hệ thống đồng bộ đơn giản

  • Luôn dùng patch, không dùng put. Put sẽ thay thế nội dung listing, vì vậy các thuộc tính bị bỏ qua có thể bị xóa. Khi thay đổi số lượng, hãy dùng patch. Amazon cũng hỗ trợ thao tác merge để chỉ cập nhật quantity bên trong fulfillment_availability, nhờ đó bạn không phải gửi lại các trường như ngày nhập hàng lại hoặc thời gian xử lý.
  • Cùng một con số nhưng có hai cách hiển thị. Phần attributes hiển thị giá trị gần nhất bạn đã gửi; phần fulfillmentAvailability hiển thị khả dụng thực tế. Ví dụ của chính Amazon: bạn gửi số lượng 1, sản phẩm được bán, nhưng attributes vẫn hiển thị 1 trong khi khả dụng thực tế là 0. Hãy đối soát theo phần trạng thái thực tế, không phải theo giá trị bạn đã gửi lần cuối.
  • Được chấp nhận không có nghĩa là đã cập nhật trực tiếp. Phản hồi của patch chỉ cho biết yêu cầu đã được tiếp nhận để xử lý. Các vấn đề phát sinh sau đó sẽ xuất hiện khi bạn gọi getListingsItem.
  • FBA không phải tồn kho bạn có thể tự đặt. Số lượng này áp dụng cho hàng do người bán tự hoàn tất đơn. Khi một listing có cả hàng FBA và hàng do người bán tự hoàn tất, hướng dẫn về nhiều phương thức hoàn tất đơn của Amazon cho biết hàng FBA sẽ được dùng trước, sau đó mới đến hàng do người bán tự hoàn tất.

Cách cập nhật tồn kho eBay bằng Inventory API

eBay chia mô hình thành hai phần. Inventory item là bản ghi ở cấp SKU, chứa tổng số lượng có thể giao tận nhà. Offer là listing riêng theo từng marketplace, được xây dựng trên SKU đó. Lệnh gọi bulkUpdatePriceQuantity có thể thay đổi tổng số lượng của tối đa 25 inventory item, cũng như giá hoặc số lượng của các offer đã xuất bản cụ thể, trong một request. Lệnh này cần OAuth scope sell.inventory.

POST https://api.ebay.com/sell/inventory/v1/bulk_update_price_quantity
{
  "requests": [
    {
      "sku": "WIDGET-BLK-01",
      "shipToLocationAvailability": { "quantity": 11 },
      "offers": [
        { "offerId": "9876543210", "availableQuantity": 11 }
      ]
    }
  ]
}

Bốn đặc điểm của eBay cần được tính đến khi thiết kế

  • Giá trị thấp hơn sẽ được ưu tiên. availableQuantity của offer là số lượng dành cho marketplace đó và không nên vượt quá tổng số lượng của SKU. Listing đang hoạt động sẽ hiển thị giá trị thấp hơn trong hai số, vì vậy giá trị offer cũ có thể âm thầm giới hạn số lượng người mua nhìn thấy. Hãy gửi cả hai giá trị cùng lúc.
  • Đọc phản hồi theo từng dòng. Phản hồi trả về trạng thái, offer ID và SKU cho từng dòng, cùng lỗi và cảnh báo riêng theo dòng. Hãy kiểm tra mọi dòng thay vì mặc định rằng toàn bộ lệnh gọi đều thành công.
  • Giới hạn 25 sản phẩm mỗi lần gọi sẽ nhanh chóng cộng dồn. Danh mục 10.000 SKU cần 400 lần gọi cho một lượt quét đầy đủ, chưa tính các lần thử lại. Hãy lập lịch quét dựa trên giới hạn này.
  • Listing cũ cần được chuyển đổi. Listing được tạo qua Inventory API không thể chỉnh sửa bằng Trading API cũ. Nếu listing eBay của bạn đến từ file CSV hoặc công cụ Trading API, hãy dùng lệnh gọi bulkMigrateListing để chuyển các listing đang hoạt động đủ điều kiện sang mô hình Inventory API trước khi tự động hóa.

Cách cập nhật tồn kho trên Walmart Marketplace

Tổng quan Marketplace Inventory API của Walmart ánh xạ từng tình huống vào một endpoint tương ứng. SKU phải được thiết lập sẵn trên Walmart trước khi bạn có thể quản lý tồn kho, và API hỗ trợ người bán tại Mỹ, Canada, Mexico và Chile.

Tình huống Endpoint
Một SKU, node giao hàng mặc định PUT /v3/inventory
Một SKU, nhiều node giao hàng PUT /v3/inventories/{SKU}
Nhiều SKU, một trung tâm hoàn tất đơn POST /v3/feeds?feedType=inventory
Nhiều SKU, nhiều node giao hàng POST /v3/feeds?feedType=MP_INVENTORY

Ship node là một trung tâm hoàn tất đơn, chẳng hạn như một kho hàng của bạn. Một bulk feed cho một node, ở định dạng JSON, có dạng như sau:

POST https://marketplace.walmartapis.com/v3/feeds?feedType=inventory
{
  "InventoryHeader": { "version": "1.4" },
  "Inventory": [
    {
      "sku": "SKU_012345",
      "quantity": { "unit": "EACH", "amount": 10 },
      "inventoryAvailableDate": "2026-10-01"
    }
  ]
}

Ba đặc điểm của Walmart cần được tính đến khi thiết kế

  • Bulk được xử lý bất đồng bộ. Gửi feed chỉ trả về feed ID, không phải kết quả. Hãy kiểm tra Feed Status API để nhận trạng thái của từng dòng và chỉ coi một dòng là hoàn tất khi trạng thái báo done.
  • Endpoint bulk có giới hạn tần suất. Hướng dẫn bulk inventory của Walmart đánh dấu các endpoint POST feed là bị giới hạn, vì vậy hãy xếp hàng các lần gửi và tăng dần thời gian chờ thay vì liên tục thử lại trong vòng lặp quá nhanh.
  • Feed nhiều node cần có ship node. Nếu không đưa ship node vào feed nhiều node, feed sẽ thất bại.

Walmart cũng cung cấp sự kiện hết hàng thông qua Notifications API. Đây là tín hiệu hữu ích để kích hoạt kiểm tra lại ngay lập tức thay vì chờ đến lượt quét tiếp theo.

So sánh cập nhật tồn kho trên Amazon, eBay và Walmart

  Amazon eBay Walmart
Cập nhật đơn lẻ patchListingsItem bulkUpdatePriceQuantity với một dòng PUT /v3/inventory
Cập nhật hàng loạt JSON_LISTINGS_FEED qua Feeds API bulkUpdatePriceQuantity, tối đa 25 item mỗi lần gọi Feed với feedType=inventory hoặc MP_INVENTORY
Cách xác nhận đã hoạt động Được chấp nhận để xử lý; đọc trạng thái thực tế bằng getListingsItem Trạng thái theo từng dòng trong phản hồi Feed ID, sau đó là trạng thái từng dòng từ Feed Status API
Ý nghĩa của số lượng Tồn kho do người bán tự hoàn tất đơn; bạn không đặt tồn FBA Tổng số lượng giao tận nhà theo SKU, cộng với khả dụng riêng của từng offer Theo từng SKU và từng ship node
Vấn đề dễ mắc nhất Dùng put và làm mất các thuộc tính Số lượng offer thấp hơn tổng SKU Feed nhiều node nhưng không có ship node

Cách ngăn bán vượt tồn kho giữa các kênh

Không thiết kế API nào có thể loại bỏ hoàn toàn tình trạng tranh chấp: hai kênh vẫn có thể bán cùng một sản phẩm trong cùng một giây. Điều bạn có thể làm là giới hạn mức độ ảnh hưởng và phát hiện thật nhanh. Các quy tắc dưới đây giúp đạt được điều đó.

  1. Trừ tồn kho trong sổ dựa trên đơn hàng, không dựa trên các lần đẩy số lượng. Vì số liệu thực tế trên Amazon có thể khác với giá trị bạn gửi lần cuối, đơn hàng mới là tín hiệu đáng tin cậy cho biết tồn kho đã giảm.
  2. Luôn đẩy số lượng tuyệt đối, không đẩy phần chênh lệch. Nếu một lần đẩy được thử lại hoặc nhận hai lần, số lượng tuyệt đối vẫn an toàn. Phần chênh lệch có thể bị tính trùng.
  3. Duy trì lượng đệm cho từng kênh. Giữ lại một vài đơn vị trên kênh bán nhanh nhất để nếu xảy ra tranh chấp, hệ thống sử dụng phần tồn kho bạn đã dự phòng.
  4. Giữ hàng ngay khi tạo đơn, sau đó tính lại cho cả ba kênh. Một đơn hàng trên eBay cần làm giảm số lượng có thể bán trên Amazon và Walmart trong cùng một chu kỳ.
  5. Đối soát bằng cách đọc lại dữ liệu. Lấy số lượng thực tế (fulfillmentAvailability của Amazon, getInventoryItem của eBay, GET /v3/inventory của Walmart) và cảnh báo khi sai lệch vượt quá mức đệm.

Lớp quy tắc có thể đơn giản như sau. Các giá trị buffer và cap chỉ mang tính minh họa; hãy điều chỉnh theo tốc độ bán của bạn.

from dataclasses import dataclass

@dataclass
class ChannelRule:
    buffer: int   # units held back from this channel
    cap: int      # max units listed here, 0 means no cap

RULES = {
    'amazon':  ChannelRule(buffer=2, cap=0),
    'ebay':    ChannelRule(buffer=3, cap=50),
    'walmart': ChannelRule(buffer=2, cap=0),
}

def sellable(channel, on_hand, reserved):
    rule = RULES[channel]
    qty = max(on_hand - reserved - rule.buffer, 0)
    return min(qty, rule.cap) if rule.cap else qty

Với 20 sản phẩm đang có và 6 sản phẩm đã được giữ cho đơn hàng, hàm này trả về 12 cho Amazon, 11 cho eBay và 12 cho Walmart. Sau đó mỗi adapter sẽ gửi số lượng riêng của mình.

Đồng bộ thời gian thực hay theo lô: nên chọn lịch nào?

Hãy dùng cả hai. Các luồng ghi dữ liệu vốn đã dẫn bạn đến cách tiếp cận này: lệnh listing của Amazon xử lý từng sản phẩm, eBay xử lý theo lô 25 sản phẩm, còn bulk của Walmart là feed bất đồng bộ. Hãy chọn phương thức dựa trên tốc độ bán của từng SKU.

Loại SKU Cách đồng bộ Lý do
Sản phẩm bán nhanh và sắp hết hàng Cập nhật theo sự kiện, gọi API từng sản phẩm sau mỗi đơn hàng Khoảng thời gian có nguy cơ bán vượt tồn rộng nhất ở nhóm này
Sản phẩm bán chậm Quét theo lịch bằng các lệnh gọi và feed bulk Ít lần gọi hơn, giảm áp lực lên giới hạn tần suất
Tất cả sản phẩm Đối soát định kỳ bằng cách đọc lại dữ liệu Khắc phục các sự kiện bị bỏ lỡ và các dòng xử lý thất bại

Hãy đặt luồng quét và luồng sự kiện trên các hàng đợi riêng, để việc thử lại liên tục trên một kênh không làm chậm các cập nhật dựa trên đơn hàng ở những kênh khác.

Tự xây dựng hay dùng công cụ đồng bộ tồn kho?

Công cụ bán sẵn dành cho bán hàng đa kênh là lựa chọn phù hợp với danh mục tiêu chuẩn trên hai hoặc ba kênh, cùng các quy tắc thông thường. Tự xây dựng sẽ hợp lý hơn khi quy tắc của bạn phức tạp: sản phẩm bundle và kit, nhiều kho hàng, giới hạn riêng theo kênh hoặc dữ liệu đơn hàng và tồn kho cần được đưa vào hệ thống ERP hay kho hàng của chính bạn.

Hãy tính cả chi phí duy trì lâu dài, không chỉ chi phí xây dựng phiên bản đầu tiên. Mỗi kênh có quy trình cấp quyền, vai trò hoặc scope riêng và cách báo lỗi riêng; cả ba cũng liên tục thay đổi. Nếu bạn muốn có một tích hợp được xây dựng theo đúng quy tắc của mình, đó là dịch vụ Netalith cung cấp trong giải pháp tích hợp marketplace cho Amazon, eBay và Walmart: listing, tồn kho, đơn hàng và tracking.

Danh sách kiểm tra trước khi vận hành

  1. Xây dựng một bảng ánh xạ SKU: SKU nội bộ với SKU Amazon, SKU eBay kèm offer ID và SKU Walmart.
  2. Chuyển các listing eBay cũ sang mô hình Inventory API.
  3. Kiểm thử từng adapter trước trong sandbox của nền tảng. eBay và Walmart đều cung cấp sandbox, còn Listings Items API của Amazon có static sandbox.
  4. Bắt đầu với mức đệm rộng và giảm dần khi dữ liệu đọc lại cho thấy không có sai lệch.
  5. Cảnh báo khi các dòng eBay bị từ chối và các dòng feed Walmart thất bại, không chỉ khi có lỗi HTTP.
  6. Lên lịch tác vụ đối soát trước khi thực sự cần đến nó.

Bạn đã có danh mục và bộ quy tắc nhưng không có thời gian xây dựng pipeline? Yêu cầu báo giá miễn phí với thông tin về các kênh và sản lượng của bạn để nhận được phương án cụ thể.

CÂU HỎI THƯỜNG GẶP

Câu hỏi thường gặp

Amazon, eBay và Walmart có thể tự đồng bộ tồn kho trực tiếp với nhau không?

Không. Mỗi marketplace chỉ tiếp nhận cập nhật tồn kho thông qua API riêng. Để đồng bộ tồn kho giữa Amazon, eBay và Walmart, bạn cần một nguồn dữ liệu trung tâm làm cơ sở chính, gửi số lượng đến từng kênh và nhận thông tin bán hàng từ các đơn hàng.

Cách nhanh nhất để cập nhật tồn kho hàng loạt trên từng marketplace là gì?

Trên Amazon, hãy dùng loại feed JSON_LISTINGS_FEED thông qua Feeds API. Trên eBay, dùng bulkUpdatePriceQuantity, hỗ trợ tối đa 25 inventory item mỗi lần gọi. Trên Walmart, gửi inventory feed với feedType=inventory, hoặc MP_INVENTORY khi cập nhật nhiều ship node.

Cập nhật số lượng qua API Amazon có thay đổi tồn kho FBA không?

Không. Số lượng bạn gửi chỉ áp dụng cho hàng do người bán tự hoàn tất đơn. Tồn kho FBA do Amazon quản lý, và khi một listing có cả hai loại tồn kho, hướng dẫn của Amazon cho biết hàng FBA sẽ được dùng trước.

Vì sao listing eBay hiển thị số lượng thấp hơn số tôi đã gửi?

eBay hiển thị giá trị thấp hơn giữa availableQuantity của offer và tổng số lượng giao tận nhà của SKU. Nếu giá trị của offer thấp hơn hoặc đã cũ, nó sẽ giới hạn số lượng người mua nhìn thấy. Hãy cập nhật cả hai giá trị trong cùng một lần gọi.

Nên chạy đồng bộ tồn kho bao lâu một lần?

Hãy dùng cập nhật theo sự kiện cho các SKU bán nhanh hoặc sắp hết hàng, quét hàng loạt theo lịch cho nhóm sản phẩm bán chậm và đọc lại dữ liệu định kỳ để phát hiện sai lệch. Dùng một khoảng thời gian cố định cho mọi SKU sẽ либо lãng phí lượt gọi, либо tạo ra khoảng thời gian bán vượt tồn quá dài.

Có thể loại bỏ hoàn toàn tình trạng bán vượt tồn giữa các marketplace không?

Không hoàn toàn, vì hai kênh có thể bán cùng một sản phẩm trong cùng thời điểm. Lượng đệm riêng cho từng kênh, cập nhật sổ tồn kho dựa trên đơn hàng, đẩy số lượng tuyệt đối và đối soát thường xuyên bằng cách đọc lại dữ liệu sẽ giúp giảm tỷ lệ này và nhanh chóng phát hiện phần còn lại.

Cập nhật cùng Netalith

Nhận kiến thức công nghệ, cập nhật sản phẩm và ưu đãi đặc biệt qua email.