Thuê lập trình viên Amazon SP-API: Cần kiểm tra gì?

Cần kiểm tra gì trước khi thuê lập trình viên Amazon SP-API?

Gọi một REST endpoint là phần đơn giản; bất kỳ lập trình viên backend nào cũng có thể làm được. Những vấn đề phát sinh khi đưa hệ thống vào vận hành lại nằm ở bốn điểm: ai sở hữu đăng ký developer, hệ thống có dựa trên các API Amazon sắp ngừng hỗ trợ hay không, hoạt động tích hợp ra sao khi Amazon giới hạn lưu lượng và dữ liệu người mua được xử lý như thế nào.

Hướng dẫn này là checklist cho cả bốn vấn đề trên, giúp chủ doanh nghiệp hoặc người phụ trách vận hành trao đổi khi tuyển dụng mà không cần đọc từng trang tài liệu API. Các thông tin dưới đây đã được đối chiếu với tài liệu chính thức của Amazon vào ngày 29 tháng 9 năm 2026.

• Quyền sở hữu: hồ sơ developer và thông tin xác thực ứng dụng phải nằm trong tài khoản của bạn, không phải tài khoản của bên nhận thầu.
• Tính cập nhật: phần việc mới phải sử dụng các phiên bản API hiện hành, không dùng API đã có ngày ngừng hỗ trợ.
• Khả năng chống gián đoạn: cơ chế xử lý giới hạn lưu lượng phải được thiết kế từ đầu, không phải đến khi triển khai mới phát hiện.
• Xử lý dữ liệu: chỉ yêu cầu những role cần thiết cho công việc và quản lý thông tin xác thực đúng cách.

Khi nào bạn thực sự cần lập trình viên SP-API?

Selling Partner API (SP-API) là REST API của Amazon, cho phép truy cập dữ liệu người bán theo cách lập trình, bao gồm listing, đơn hàng, khoản thanh toán, báo cáo và nhiều dữ liệu khác. Bạn cần lập trình viên khi một connector có sẵn không thể đáp ứng logic của mình, chẳng hạn như điều phối tồn kho giữa nhiều kho, đưa đơn hàng vào hệ thống ERP riêng hoặc xây dựng công cụ cho những người bán khác. Nếu connector có sẵn đã đáp ứng được luồng dữ liệu, việc xây dựng hệ thống riêng có thể tạo thêm gánh nặng bảo trì mà bạn không thực sự cần.

Bảng dưới đây liên kết các nhu cầu phổ biến với khu vực API liên quan và những điểm thường phát sinh vấn đề.

Ai sở hữu tài khoản developer SP-API?

Để gọi SP-API, bạn cần có developer profile trong Amazon's Solution Provider Portal và một ứng dụng đã đăng ký. Amazon chia developer thành hai loại. Private developer xây dựng ứng dụng chỉ tích hợp công ty của họ với Amazon, và các ứng dụng này được tự cấp quyền. Public developer xây dựng ứng dụng cho những người bán khác, nên ứng dụng công khai có các giới hạn cấp quyền riêng.

Nếu bạn thuê người xây dựng hệ thống cho cửa hàng của mình, bạn muốn trở thành private developer. Có ba điểm cần làm rõ trong cuộc trao đổi:

• Chỉ người dùng chính của tài khoản mới có thể hoàn tất đăng ký. Bên nhận thầu không thể tự đăng ký thay bạn từ phía họ, vì vậy chủ tài khoản phải tham gia.
• Amazon là bên quyết định phê duyệt. Quyết định dựa trên developer profile của bạn, bao gồm chức năng của ứng dụng và việc tuân thủ Acceptable Use Policy cũng như Data Protection Policy. Amazon cho biết họ không thể giải thích chi tiết cách xác định điều kiện đủ tư cách. Amazon cũng yêu cầu hồ sơ dưới 500 từ, dùng cách diễn đạt nguyên bản thay vì sao chép nội dung chính sách, đồng thời để đội ngũ kỹ thuật trả lời các câu hỏi bảo mật.
• Role bị giới hạn đồng nghĩa với PII. Những role cho phép truy cập thông tin nhận dạng cá nhân sẽ bị xem xét nghiêm ngặt hơn. Với public developer, việc này bao gồm đánh giá kiến trúc với đội ngũ SP-API Solutions Architecture của Amazon và có thể cần trình diễn qua chia sẻ màn hình.

Vì bạn không kiểm soát được thời điểm phê duyệt, hãy xây dựng các mốc dự án không phụ thuộc vào một ngày phê duyệt cụ thể. Đề nghị ứng viên cùng bạn soạn nội dung mô tả use case, đồng thời giữ việc đăng ký ứng dụng và thông tin xác thực trong chính tài khoản của mình. Amazon cung cấp tính năng quản lý người dùng trong Solution Provider Portal, vì vậy lập trình viên nên làm việc bằng user riêng thay vì dùng chung thông tin đăng nhập chính. Thông tin xác thực cũng cần được thay mới định kỳ, và Amazon cung cấp thông báo thay mới thông qua Application Management API.

Hãy cẩn trọng với đề xuất nói rằng chúng tôi sẽ dùng tài khoản developer của mình cho cửa hàng của bạn. Đây có thể là mô hình public app hợp lệ, nhưng đó là thuê quyền sử dụng chứ không phải sở hữu: nếu quan hệ hợp tác kết thúc, hệ thống tích hợp của bạn vẫn gắn với ứng dụng của họ.

Những thay đổi API mà một lập trình viên giỏi phải biết

Amazon công bố lịch ngừng hỗ trợ SP-API kèm các ngày gỡ bỏ. Trong lịch này, deprecated nghĩa là tài nguyên không còn được phát triển tích cực, còn removed nghĩa là các lệnh gọi sẽ thất bại kể từ ngày gỡ bỏ. Lịch được cập nhật lần cuối vào ngày 9 tháng 9 năm 2026. Dưới đây là những mục quan trọng với một hệ thống mới, cùng trạng thái tại ngày 29 tháng 9 năm 2026:

Điều gì thay đổi khi Orders v0 chuyển sang v2026-01-01?

Orders là API mà hầu hết hệ thống tích hợp chạm đến đầu tiên, vì vậy đây là đợt chuyển đổi nhiều khả năng sẽ đến với bạn nhất. Phiên bản thay thế là Orders API v2026-01-01, và khác biệt không chỉ nằm ở việc đổi tên lệnh gọi:

Có hai hệ quả thực tế. Thứ nhất, một hệ thống tích hợp hiện có được viết trên Orders v0 hoặc XML feed là một dự án chuyển đổi có thời hạn bắt buộc, không phải chỉnh sửa nhỏ; hãy lập phạm vi và báo giá tương xứng. Thứ hai, bất kỳ đề xuất mới nào dựa trên v0 hoặc XML feed đều cho thấy ứng viên đang làm việc theo các hướng dẫn cũ.

Một dấu hiệu liên quan: kể từ ngày 2 tháng 10 năm 2023, SP-API không còn yêu cầu AWS IAM hoặc AWS Signature Version 4 để gọi API. Một đề xuất dành nhiều ngày cho IAM role và ký request chỉ để thực hiện lệnh gọi là dấu hiệu đã lỗi thời. AWS vẫn được sử dụng nếu bạn dùng Amazon SQS hoặc EventBridge để nhận notification, vì vậy câu trả lời chính xác là IAM đã rời khỏi luồng request, chứ không phải khỏi toàn bộ kiến trúc.

Chi phí thuê lập trình viên Amazon SP-API năm 2026

Có hai nhóm chi phí, và nhóm đầu tiên đã giảm trong năm nay. Vào tháng 11 năm 2025, Amazon công bố phí developer cho SP-API, gồm phí thuê bao hằng năm và phí sử dụng dựa trên số lượng lệnh gọi GET. Đến ngày 12 tháng 5 năm 2026, Amazon thông báo với các developer rằng họ sẽ chưa triển khai phí sử dụng và phí hằng năm vào thời điểm hiện tại, nên tại thời điểm bài viết này không cần dự trù phí từ phía Amazon.

Hãy xem cụm từ vào thời điểm hiện tại là lý do để hỏi ứng viên thiết kế của họ sẽ thích ứng thế nào nếu tính phí theo từng lệnh gọi. Một hệ thống tích hợp lắng nghe notification thay vì polling theo bộ hẹn giờ sẽ có chi phí vận hành thấp hơn dưới bất kỳ mô hình tính phí nào. Hướng dẫn riêng của Amazon dành cho ứng dụng bị giới hạn lưu lượng cũng đưa ra khuyến nghị tương tự: dùng push notification thay cho polling.

Nhóm chi phí thứ hai là phí của lập trình viên. Thay vì đưa ra mức giá dễ lỗi thời, dưới đây là những yếu tố thực sự làm thay đổi chi phí:

Hãy yêu cầu báo giá dựa trên phạm vi công việc được ghi rõ. Mức giá theo giờ nhưng không có phạm vi cụ thể sẽ khiến bạn phải gánh rủi ro từ mọi vấn đề phát sinh trong bảng trên. Nếu muốn có người cùng xây dựng phạm vi, dịch vụ tích hợp marketplace của Netalith bao gồm listing, tồn kho, đơn hàng và tracking trên Amazon SP-API, với chi phí được tính theo phạm vi luồng dữ liệu.

Câu hỏi giúp phân biệt kinh nghiệm SP-API thực tế với việc chỉ học theo tutorial

Những câu hỏi này đều có câu trả lời có thể kiểm chứng. Mỗi câu gắn với hành vi được mô tả trong tài liệu Amazon, vì vậy ứng viên từng vận hành thực tế sẽ trả lời nhanh và cụ thể.

Có một điểm cần nhấn mạnh vì thường khiến nhiều người bất ngờ. Với các thao tác sử dụng usage plan động, Amazon điều chỉnh rate limit cho từng selling partner dựa trên các chỉ số kinh doanh, không dựa trên số request mà ứng dụng gửi đi; gọi thường xuyên hơn cũng không làm tăng giới hạn. Cách khắc phục hệ thống bị throttling là giảm số lượng lệnh gọi và thiết kế chúng tốt hơn, chứ không phải gây áp lực lên Amazon.

Nên thuê freelancer, agency hay tuyển nội bộ?

Lựa chọn phù hợp phụ thuộc vào tính liên tục của công việc nhiều hơn là kỹ năng, vì một hệ thống tích hợp SP-API cần được duy trì. Các mốc ngừng hỗ trợ trong lịch của Amazon trải dài qua ba năm liên tiếp, nên nếu thuê xây dựng xong rồi kết thúc hợp tác, bạn có thể bị bỏ lại khi API tiếp theo bị gỡ bỏ.

Điều khoản hợp đồng bảo vệ hệ thống tích hợp Amazon

• Code nằm trong repository của bạn. Mã nguồn và định nghĩa hạ tầng thuộc về bạn và được lưu trong tổ chức do bạn kiểm soát.
• Đăng ký và thông tin xác thực nằm trong tài khoản của bạn. Developer profile, đăng ký ứng dụng và thông tin xác thực phải thuộc doanh nghiệp của bạn; lập trình viên được thêm vào với tư cách user.
• Phân công rõ trách nhiệm theo dõi API sắp ngừng hỗ trợ. Hợp đồng phải nêu rõ ai theo dõi lịch ngừng hỗ trợ của Amazon và ai chuyển đổi hệ thống trước từng ngày gỡ bỏ.
• Có runbook. Tài liệu phải bao gồm throttling, feed thất bại hoặc issue của listing, thông tin xác thực hết hạn và cách cấp quyền lại.
• Điều khoản xử lý dữ liệu. Dữ liệu người mua được xử lý phù hợp với Data Protection Policy của Amazon và chỉ yêu cầu những role cần thiết cho công việc.
• Nghiệm thu bằng traffic thực tế. Các mốc thanh toán phải phụ thuộc vào việc đơn hàng hoặc listing thực sự đi qua production, không chỉ dựa trên bản demo sandbox.

Cách nhận báo giá có phạm vi rõ ràng cho hệ thống tích hợp Amazon

Để có thể so sánh các báo giá, hãy gửi cùng một bộ bốn thông tin cho mọi ứng viên: bạn đang bán trên những marketplace Amazon nào, muốn tự động hóa những luồng dữ liệu nào, dữ liệu cần được đưa đến hệ thống nào và liệu code hiện tại có chạy trên Orders v0 hoặc XML feed hay không. Bốn câu trả lời này quyết định phần lớn chi phí và rủi ro.

Nếu muốn Netalith xây dựng phạm vi cho dự án, hãy dùng 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.