Toàn bộ thay đổi của bộ API Sàn Cam, mới nhất ở trên. Cần tài liệu API hiện hành thì xem trang Sàn Cam APIs.
Gõ tên sản phẩm, nhận về bức tranh cả thị trường của từ khoá đó trong một request: tổng số sản phẩm, tổng lượt bán, tổng doanh thu, số shop, mức độ cạnh tranh, kèm danh sách sản phẩm sắp theo doanh thu. Chạy trên kho dữ liệu đã thu thập nên không tiêu quota nguồn — gọi bao nhiêu cũng không ảnh hưởng hạn mức của các endpoint khác.
GET /search/market.php?q=áo mưa
GET /search/market.php?q=kem chống nắng
&price_min=100000&sort=comm_rate
Trả toanCanh (tổng hợp cả thị trường), topShop, sanPham (tối đa 200 dòng) và các chỉ số cạnh tranh.
"ao mua" và "áo mưa" cho cùng kết quả. Chữ hoa, dấu câu, emoji hay chữ trang trí kiểu 𝑪𝒉í𝒏𝒉 𝒉ã𝒏𝒈 trong tên sản phẩm đều được xử lý.
Mức độ tập trung thị trường (HHI), điểm "đại dương xanh", tỷ lệ sản phẩm bán được, độ biến thiên giá và nhịp tăng trưởng của từng sản phẩm.
"áo mưa" chỉ khớp đúng cụm đó, không khớp "áo thun… mua 2 tặng 1". Ít kết quả quá thì tự nới lỏng dần — và báo lại mức đã dùng, không im lặng đổi nghĩa truy vấn của bạn.
💡 Phản hồi thường 0,3 giây, lần gọi lặp lại còn 0,09 giây nhờ cache 6 giờ. Lưu ý khi đọc số: phạm vi là kho dữ liệu đã thu thập chứ không phải toàn sàn, và toanCanh là số luỹ kế — số theo kỳ 30 ngày nằm riêng kèm độ phủ. Tài liệu đầy đủ: Market Search API.
Hệ thống đã tích luỹ lịch sử giá và lịch sử hoa hồng theo ngày từ lâu, nhưng trước nay chỉ moi ra được từng sản phẩm một và chỉ có giá. Giờ có endpoint đọc thẳng kho đó: nhiều sản phẩm một lượt, chọn được loại dữ liệu, và không gọi API nguồn lần nào nên không tiêu quota Sàn Cam.
GET /price-tracking/history.php
?item_ids=1589295236,45703342049
&type=both&days=90
type nhận price · commission · both (có cả alias tiếng Việt gia, hoahong). Tới 50 sản phẩm/request, tối đa 730 ngày.
changes_only=1 — nên bậtchanges_only=0 → 90 điểm, 18 KB changes_only=1 → 5 điểm, 2,1 KB
Chỉ trả những ngày giá thật sự đổi. Đo trên dữ liệu thật: 90 ngày mà chỉ 4 lần đổi giá — cắt 88% dung lượng mà không mất thông tin, vì giá giữa hai mốc chính là giá của mốc trước.
"stats": { min, max, avg, changeCount,
changePercent, isLowest… }
"allTime": { currentPrice, minPrice,
maxPrice, priceChange30d… }
stats theo khoảng ngày đang hỏi, allTime là toàn thời gian. Khỏi tự tính lại phía bạn. Bật changes_only vẫn không làm sai thống kê.
base_ratekhông khai tier → 15 lần "đổi" HH base_rate=8&cap=20000 → 4 lần
% HH Sàn trong lịch sử là của tài khoản đã lấy dữ liệu ngày hôm đó, mà hệ thống xoay vòng nhiều tài khoản khác tier — nên chuỗi nhảy dù sàn chẳng đổi gì. Khai tier của bạn thì toàn chuỗi tính lại theo đúng một mức, vẫn giữ khối recorded để đối chiếu. Không khai thì endpoint tự cảnh báo chứ không im lặng.
format=chart"chart": {
"labels": ["2026-06-25", …],
"price": [175000, 115100, …]
}
Trả mảng song song thay cho mảng object — cắm thẳng vào Chart.js, khỏi tự map. Nhẹ hơn 82% (90 ngày cả hai loại: 47,5 KB xuống 8,7 KB).
Mỗi sản phẩm một dòng mỗi ngày. Giá đổi nhiều lần trong cùng một ngày thì chỉ còn lại lần ghi cuối của ngày đó.
Cần giá hiện tại chứ không phải lịch sử thì dùng Product Data Batch.
💡 Vì thuần đọc database nên endpoint này không đụng tới quota Sàn Cam — gọi thoải mái hơn hẳn các endpoint có fetch. Giới hạn 600 sản phẩm/phút theo IP. Tài liệu đầy đủ: Price & Commission History API.
Có endpoint mới lấy nhiều sản phẩm trong một request. Trước đây muốn làm tươi vài nghìn sản phẩm thì phải gọi endpoint đơn vài nghìn lần; nay gửi tối đa 100 item_id mỗi lượt, phần đã có trong cache trả về ngay, chỉ sản phẩm chưa có mới phải chờ nguồn.
GET /product-data/product-data-batch.php
?item_ids=1589295236,45703342049
POST /product-data/product-data-batch.php
{"item_ids": [1589295236, 45703342049]}
Nhận mảng JSON, item_ids[]=…, hay chuỗi ngăn bằng dấu phẩy / xuống dòng. Đo thực tế: 100 sản phẩm từ cache trả về trong ~0,33 giây.
Giới hạn đếm theo sản phẩm, không theo số request:
cache : 2.000 sản phẩm/phút gọi nguồn: 300 sản phẩm/phút
Sản phẩm đã nằm trong cache chỉ ăn quota cache. Hết quota nguồn giữa chừng không trả 429 cho cả lô — phần cache vẫn về bình thường, phần còn lại gắn cờ để bạn gửi lại.
sub_id riêng từng sản phẩm{"affid": "12345678901", "items": [
{"item_id": 1589295236, "sub1": "userA"},
{"item_id": 1589295236, "sub1": "userB"}
]}
Cùng một sản phẩm gửi cho nhiều người mà vẫn tách được hoa hồng theo từng người. Không khai riêng thì dùng sub_id chung của cả lô.
status để biết cái nào cần gọi lạisuccess → dùng luôn stale → có dữ liệu nhưng là bản cũ skipped → chưa kịp gọi nguồn lượt này not_found→ nguồn cũng không có error → đầu vào hỏng
Gom stale + skipped gửi lại vòng sau, thay vì quét lại cả 5.000 sản phẩm. Mỗi mục có thêm reason nói rõ vì sao.
💡 Endpoint 1 sản phẩm không đổi gì — product-data.php giữ nguyên URL, tham số và response. Batch là endpoint riêng, dùng chung kho cache nên dữ liệu hai bên luôn khớp nhau.
API giờ trả kèm danh mục của sản phẩm. Trước đây muốn biết sản phẩm thuộc ngành hàng nào thì phải tự đoán từ tên — nay có catId ngay trong response, phân loại sản phẩm hoặc lọc theo ngành hàng chính xác hơn hẳn.
catId · catIds"catId": 100892, "catIds": [100630, 100664, 100892]
catIds là đường dẫn danh mục từ ngành hàng gốc xuống danh mục cụ thể nhất; catId chính là phần tử cuối — thứ bạn thường cần. Đây là id danh mục của Sàn Cam, dùng làm khoá phân loại được.
catName · catPath"catName": "Nước cân bằng da", "catPath": ["Sắc Đẹp", "Nước cân bằng da"]
Sàn Cam chỉ cấp id chứ không cấp tên, nên tên ở đây do hệ thống tự đối chiếu mà có — hiện phủ khoảng 58% số danh mục. Chỗ chưa biết tên thì bỏ hẳn field, không trả null.
catId làm khoá, đừng dùng tênHai điều cần nhớ khi code:
// catName/catPath CÓ THỂ KHÔNG TỒN TẠI
if (p.catName) { … }
// catPath KHÔNG khớp vị trí với catIds
catIds: [100011, 100049]
catPath: ["Thời Trang Nam"] // 2 id, 1 tên
Cấp nào chưa biết tên thì bị bỏ qua nên catPath có thể ngắn hơn catIds. Cần chắc chắn thì đọc catIds.
Đã nâng bộ nhớ đệm database. Đo trên cùng tập sản phẩm:
p50: 36,5ms → 25,1ms p95: 90,2ms → 40,1ms
Nhanh rõ nhất ở các request vốn chậm (p95 giảm hơn một nửa). Request phải gọi ra API nguồn vẫn ~180–200ms — phần đó nằm ngoài tầm với.
💡 Tương thích ngược hoàn toàn — chỉ thêm field mới, không đổi tên hay bỏ field nào. Tool đang tích hợp chạy bình thường, không cần sửa gì.
API giờ trả luôn link affiliate cho sản phẩm. Chỉ cần thêm affid vào request là có ngay long-link chuẩn 2026 (cơ chế an_redir) — không phải tự encode landing, tự ghép sub_id hay lo sai cấu trúc mất hoa hồng. Xem hướng dẫn tạo link Aff 2026.
affidKhai affiliate ID của bạn, response có thêm affLink:
?item_id=1589295236&affid=12345678901 "affLink": "https://s.shopee.vn/an_redir ?origin_link=https%3A%2F%2Fshopee.vn%2F… &affiliate_id=12345678901"
Nhận cả aff_id / affiliate_id. Không truyền thì affLink = null — server không giữ affiliate ID mặc định.
sub_id từ URLTruyền theo từng vị trí hoặc cả chuỗi đã ghép sẵn, API tự chuẩn hoá:
&sub1=kolA&sub2=tet26&sub4=post9 &sub_id=kolA-tet26-fb-post9-note
Tối đa 5 vị trí. Dấu - bên trong 1 sub đổi thành _ (nếu không Sàn Cam hiểu nhầm thành vị trí mới); vị trí trống ở giữa vẫn giữ để không lệch thứ tự.
Link gốc được gỡ sạch tham số tracking (utm_*, gads_*, sp_atk…) trước khi gắn affiliate — đúng policy mới, tránh mất hoa hồng.
Domain tự theo quốc gia của link (shopee.co.id → s.shopee.co.id/an_redir). Link rút gọn không được dùng làm landing nên sẽ trả null.
productInfo"shopId": 38003654, "originLink": "https://shopee.vn/product/…", "affiliateId": "12345678901", "subId": "kolA-tet26--post9", "affLink": "https://s.shopee.vn/an_redir?…"
Chỉ thêm mới, không đổi tên field cũ — productLink giữ nguyên, tool đang tích hợp chạy bình thường.
💡 Mẹo: dùng sub_id thống nhất theo kênh (KOL · chiến dịch · nguồn · post · ghi chú) để đối soát hiệu quả từng nơi đăng. Cần link ngắn đẹp thì đưa affLink qua Short Link Manager.
Hoa hồng Sàn Cam khác nhau theo từng tài khoản affiliate (HH Sàn 3,5% / 5% / 8%, cap 40.000₫ hoặc 20.000₫). API chạy bằng tài khoản proxy phía server, nên từ bản này bạn có thể tự khai tier của mình để nhận đúng số tiền tài khoản bạn được hưởng.
Một số sản phẩm bị cache ghi đè hoa hồng Sàn Cam thành 0₫ dù thực tế vẫn có. API giờ tự phát hiện và gọi lại nguồn để lấy số đúng trước khi trả về, thay vì hiển thị dữ liệu hỏng.
Sản phẩm thật sự 0% (do ngành hàng không có HH Sàn) vẫn giữ 0₫ và không bị gọi lại liên tục.
base_rateKhai % HH Sàn theo tier tài khoản của bạn. Nhận cả dạng thập phân và phần trăm:
?item_id=45703342049&base_rate=8 ?item_id=45703342049&base_rate=0.08
Không truyền thì dùng rate của tài khoản proxy.
capTrần hoa hồng Sàn Cam theo VNĐ của tài khoản bạn (mặc định 40.000₫):
?item_id=45703342049&cap=20000
Kết hợp được: &base_rate=8&cap=20000
Trước đây chỉ có số tiền, giờ có thêm cả tỷ lệ để bạn đối chiếu:
"sellerRatePercent": 2, "shopeeRatePercent": 3.5, "totalRatePercent": 5.5, "shopeeRateSource": "api_or_db"
Trường imageUrl từ cache trả về id thô (thiếu tiền tố CDN) khiến thẻ <img> hỏng. Giờ luôn là URL đầy đủ.
- "vn-11134207-81ztc-mokndumot3pe94" + "https://down-vn.img.susercontent.com/file/vn-1113…"
Không có field nào bị đổi tên hoặc xoá bỏ — chỉ thêm mới. Các tool đang tích hợp chạy bình thường, không cần sửa gì.
Trần HH Sàn theo % giá cũng được nâng từ 7% lên 8%.
⚠️ Lưu ý: HH Seller (Xtra) không bị ảnh hưởng bởi base_rate lẫn cap — Xtra không có trần. Nếu Sàn Cam trả HH Sàn = 0 vì ngành hàng không có hoa hồng sàn thì base_rate cũng không ghi đè được.