Chi phí tích hợp Amazon SP-API năm 2026: Bạn thực sự trả gì?

Chi phí tích hợp Amazon SP-API là bao nhiêu?

Tính đến ngày 29 tháng 9 năm 2026, Amazon không thu phí khi bạn gọi Selling Partner API (SP-API). Amazon đã hủy cả phí đăng ký nhà phát triển hằng năm lẫn phí sử dụng tính theo số lần gọi API từng được công bố trước đó, vì vậy khoản phí nền tảng trong ngân sách của bạn là 0 USD. Mọi chi phí bạn trả cho một dự án tích hợp Amazon SP-API đều nằm ở phần công việc xung quanh API: xác định phạm vi, lập trình, hồ sơ đăng ký và bảo mật, cũng như duy trì tích hợp sau khi đưa vào hoạt động.

Điều này làm thay đổi cách bạn đọc một báo giá. Một mức giá duy nhất cho việc kết nối với Amazon thường gộp ít nhất bốn hạng mục khác nhau (được trình bày bên dưới), và chi phí thay đổi theo những gì bạn cần tích hợp thực hiện, chứ không phải theo số lượng endpoint mà nó gọi.

Hướng dẫn này cố ý không đưa ra một con số cố định bằng USD. Chi phí xây dựng phụ thuộc vào phạm vi, và một con số không gắn với phạm vi cụ thể chỉ là thông điệp tiếp thị, không phải ước tính. Thay vào đó, bạn sẽ có cấu trúc chi phí, những yếu tố làm thay đổi giá và danh sách kiểm tra để thu thập các báo giá có thể so sánh thực sự.

Năm 2026, Amazon có thu phí truy cập SP-API không?

Không. Amazon từng công bố hai khoản phí dành cho nhà phát triển bên thứ ba: phí đăng ký hằng năm và phí sử dụng dựa trên số lần gọi API. Sau đó, Amazon đã đăng thông báo hủy cả hai khoản phí, đồng thời cho biết quyền truy cập SP-API của bên thứ ba vẫn miễn phí.

Có ba chi tiết cần lưu ý khi lập ngân sách:

• Cách diễn đạt cho thấy chính sách này có thể thay đổi. Amazon nói rằng họ sẽ không triển khai các khoản phí “vào thời điểm này”, nhưng điều đó không có nghĩa là phí sẽ không bao giờ quay trở lại. Hãy xem 0 USD là mức giá hiện tại, không phải mức giá vĩnh viễn.
• Thông báo không ghi ngày. Trang này không có ngày đăng, vì vậy hãy kiểm tra lại trước khi ký hợp đồng dài hạn dựa trên giả định quyền truy cập luôn miễn phí.
• Bạn phải tự xử lý việc dọn dẹp. Amazon cho biết họ sẽ xóa bảng điều khiển xem trước phí và cho phép nhà phát triển xóa thẻ thanh toán từng nhập vào Solution Provider Portal. Nếu đã thêm thẻ trong giai đoạn xem trước, hãy xóa thẻ đó.

Thông báo được viết cho các nhà phát triển bên thứ ba. Nếu bạn là nhà cung cấp giải pháp hoặc không chắc mình thuộc loại nhà phát triển nào, hãy xác nhận trong Solution Provider Portal thay vì tự suy đoán.

Lời khuyên thực tế của chúng tôi: hãy xây dựng hệ thống như thể các lần gọi API có thể bị tính phí trở lại. Thiết kế tiết kiệm số lần gọi (được đề cập trong phần về giới hạn tốc độ) sẽ giúp giảm chi phí vận hành dưới bất kỳ mô hình tính phí nào.

Bốn nhóm chi phí của một dự án tích hợp SP-API

Mọi chi phí của dự án SP-API đều thuộc một trong bốn nhóm dưới đây. Những báo giá chỉ nêu nhóm thứ ba là chưa đầy đủ.

Nhóm 3 thường là khoản lớn nhất trên hóa đơn đầu tiên. Nhóm 4 quyết định tổng chi phí tích hợp trong hai năm, và đây cũng là hạng mục thường bị bỏ sót nhất trong ước tính ban đầu.

Ứng dụng private hay public: Yếu tố ảnh hưởng chi phí lớn nhất

Quyết định đầu tiên định hình mức giá là ứng dụng phục vụ ai. Tổng quan đăng ký SP-API của Amazon phân biệt ứng dụng private, được tự ủy quyền và chỉ giới hạn trong tổ chức của bạn, với ứng dụng public, cho phép mọi người bán ủy quyền thông qua OAuth và bắt buộc phải được niêm yết trên Amazon Selling Partner Appstore.

Nếu bạn bán hàng trên chính các tài khoản của mình và muốn kết nối hệ thống nội bộ, ứng dụng private là lựa chọn mặc định. Phạm vi thường phình to khi doanh nghiệp xây dựng thiết kế multi-tenant cho nhu cầu chỉ có một người bán vì cho rằng cách này “sẵn sàng hơn cho tương lai”. Đây cũng là kiểu chuẩn bị cho tương lai tốn kém nhất, vì bạn phải chi trả cho mọi yêu cầu của ứng dụng public trước cả khi có khách hàng thứ hai.

Điều gì quyết định chi phí xây dựng: Phạm vi, không phải số endpoint

Các đội ngũ thường ước tính bằng cách đếm số thao tác API. Đây là đơn vị đo không phù hợp. Chi phí nằm ở quy trình xoay quanh từng chức năng: trạng thái, xác thực, thử lại và đối soát. Các nhãn dưới đây là đánh giá của chúng tôi về mức độ nỗ lực tương đối giữa các chức năng, không phải số giờ ước tính.

Ngoài các chức năng, bốn yếu tố khuếch đại sau cũng làm thay đổi giá:

• Marketplace và khu vực. Mỗi tài khoản khu vực có seller ID riêng, còn giới hạn tốc độ được tính theo từng người bán, vì vậy thêm một khu vực gần như tương đương với thêm một tích hợp, chứ không chỉ là thay đổi một cài đặt.
• Số lượng tài khoản người bán. Nhiều tài khoản hơn đồng nghĩa với nhiều quyền ủy quyền cần quản lý hơn và nhiều trạng thái lỗi hơn cần giám sát.
• Khối lượng dữ liệu. Vài trăm SKU và vài trăm nghìn SKU đòi hỏi hai kiến trúc khác nhau.
• Chất lượng dữ liệu của chính bạn. Công việc listing sẽ bị đình trệ nếu catalog không ánh xạ rõ ràng vào các yêu cầu về loại sản phẩm của Amazon. Làm sạch dữ liệu thường là dự án ẩn bên trong dự án tích hợp.

Giới hạn tốc độ SP-API chuyển thành chi phí kỹ thuật như thế nào?

Giới hạn tốc độ không phải là một khoản phí, nhưng đây là nơi ngân sách phát sinh ngoài dự kiến. SP-API sử dụng cơ chế token bucket: token được nạp lại với tốc độ ổn định mỗi giây cho đến một mức burst tối đa, mỗi yêu cầu tiêu tốn một token và bucket trống sẽ trả về phản hồi 429. Giới hạn áp dụng cho từng cặp ứng dụng và đối tác bán hàng, vì vậy cùng một ứng dụng sẽ có một bucket riêng cho mỗi người bán mà nó phục vụ.

Amazon sử dụng hai loại usage plan. Standard plan có giới hạn tĩnh được công bố. Dynamic plan điều chỉnh theo từng đối tác bán hàng dựa trên quy mô và hành vi kinh doanh của người bán đó. Amazon nêu rõ rằng giới hạn không tăng chỉ vì ứng dụng gọi API thường xuyên hơn, nên việc liên tục bị giới hạn là vấn đề thiết kế, không phải thứ có thể giải quyết bằng cách trả thêm tiền.

Hệ quả chi phí rất cụ thể:

• Các vòng lặp qua từng SKU sẽ không thể đáp ứng khi tăng trưởng. Chúng hoạt động trong bản demo nhưng bắt đầu trả về lỗi 429 ở khối lượng thực tế, và việc viết lại sẽ tốn kém hơn so với thiết kế đúng ngay từ đầu.
• Bắt buộc phải có cơ chế back-off. Lỗi 429 có thể thử lại, nhưng các lần gọi bị giới hạn liên tiếp cần chiến lược back-off, và lỗi 429 tạm thời vẫn có thể xảy ra ngay cả trong ứng dụng được xây dựng tốt.
• Không hardcode bộ hẹn giờ. Header phản hồi về giới hạn tốc độ không được đảm bảo luôn xuất hiện, vì vậy hãy đọc giới hạn khi có thể và thiết kế dựa trên sự kiện thay vì thời gian chờ cố định.
• Ưu tiên push và xử lý hàng loạt. Hướng dẫn của Amazon là dùng notification thay cho polling, đồng thời sử dụng Feeds API và Reports API để truyền nhiều dữ liệu hơn trong mỗi lần gọi.

Lập ngân sách cho thiết kế hướng sự kiện ngay từ đầu sẽ ít tốn kém hơn so với việc bổ sung nó sau sự cố đầu tiên trên môi trường production.

Công việc đăng ký và bảo vệ dữ liệu thường bị bỏ sót trong báo giá

Đăng ký không tốn tiền, nhưng tốn thời gian và có thể trì hoãn ngày ra mắt. Theo tổng quan đăng ký, ứng viên phải hoàn thiện hồ sơ nhà phát triển, bao gồm các câu hỏi về kiểm soát bảo mật cần đội ngũ kỹ thuật tham gia, phần mô tả nguyên bản bằng văn bản dưới 500 từ, lựa chọn role phù hợp với các thao tác API sẽ sử dụng và thông tin về cách bảo vệ dữ liệu. Bạn cũng cần xem xét Acceptable Use Policy và Data Protection Policy của Amazon, đồng thời triển khai các biện pháp kiểm soát bảo mật chính như quản lý lỗ hổng, bảo vệ mạng và mã hóa dữ liệu.

Trang này không công bố thời gian xét duyệt hay phí đăng ký. Vì vậy, hãy lập kế hoạch cho những phần bạn có thể kiểm soát:

• Chỉ yêu cầu các role cần thiết cho hoạt động, không yêu cầu nhiều hơn. Quyền truy cập rộng hơn đồng nghĩa với việc phải giải trình nhiều hơn.
• Đưa người phụ trách hạ tầng vào quy trình từ sớm. Các câu hỏi bảo mật được đưa ra vào phút cuối là nguyên nhân kinh điển khiến ngày ra mắt trễ một hoặc hai tuần.
• Đừng cam kết ngày go-live với các bên liên quan cho đến khi hồ sơ được phê duyệt. Amazon không công bố thời gian xử lý cố định mà bạn có thể dựa vào.

Tự xây dựng, thuê nhà phát triển hay dùng công cụ đa kênh?

Lựa chọn phù hợp phụ thuộc vào việc logic của bạn có bao nhiêu phần là tiêu chuẩn và bao nhiêu phần mang tính riêng biệt của doanh nghiệp.

Trường hợp ở giữa là nơi thường phát sinh bất ngờ về chi phí: đồng bộ marketplace tiêu chuẩn cộng với các quy tắc chỉ doanh nghiệp của bạn có, chẳng hạn logic định giá, phân tuyến kho hoặc kế toán riêng. Nếu đó là tình huống của bạn, dịch vụ tích hợp marketplace của Netalith hỗ trợ listing, tồn kho, đơn hàng và tracking trên Amazon SP-API cùng các marketplace khác.

Cách nhận báo giá có thể so sánh

Các báo giá chỉ có thể so sánh khi cùng trả lời một bộ câu hỏi. Hãy gửi cùng một bản yêu cầu cho mọi nhà phát triển:

1. Các tài khoản người bán và marketplace hoặc khu vực nằm trong phạm vi.
2. Ứng dụng private hay public, và lý do lựa chọn.
3. Các chức năng cần dùng trong bảng trên, được xếp theo mức độ ưu tiên.
4. Khối lượng: SKU, số đơn mỗi ngày, tần suất cập nhật.
5. Các hệ thống ở đầu kia của luồng đồng bộ và hệ thống nào là nguồn dữ liệu chuẩn.
6. Bạn có cần dữ liệu người mua hay không, vì điều này kích hoạt quy trình xử lý dữ liệu bị hạn chế.
7. Ai hoàn tất đăng ký và ai chịu trách nhiệm quản lý thông tin xác thực của tài khoản người bán.
8. Kỳ vọng về giám sát, hỗ trợ và thay đổi phiên bản API sau khi ra mắt.

Sau đó, hãy đọc câu trả lời để phát hiện các dấu hiệu cảnh báo:

• Mức giá cố định cho một dự án tích hợp Amazon hoàn chỉnh nhưng không có danh sách chức năng.
• Không đề cập đến đăng ký, câu trả lời bảo mật hoặc rủi ro phê duyệt.
• Không có hạng mục vận hành sau khi ra mắt.
• Giải thích chi phí bằng các khoản phí Amazon đã hủy.

Nếu muốn nhận ước tính theo phạm vi thay vì tự viết bản yêu cầu, hãy gửi các câu trả lời đó qua biểu mẫu nhận báo giá miễn phí của Netalith và chọn dịch vụ tích hợp marketplace.