StoreFleet
Trang chủBlog › Giới hạn API của Shopify: Quản lý nhiều cửa hàng

Giới hạn API của Shopify: Quản lý nhiều cửa hàng

Cách hiểu giới hạn tần suất gọi (rate limit) của Shopify REST và GraphQL API khi vận hành nhiều cửa hàng, bao gồm cơ chế leaky bucket, mô hình chi phí truy vấn và các chiến lược tránh bị throttling.

Cập nhật 2026-06-20

Vận hành nhiều cửa hàng Shopify từ một nền tảng duy nhất tạo ra một thách thức rất riêng: bạn không chỉ chạm đến giới hạn API của một cửa hàng, mà còn dồn áp lực rate-limit lên hàng chục, thậm chí hàng trăm cửa hàng cùng lúc. Hiểu rõ cách các hệ thống giới hạn tần suất gọi API của Shopify hoạt động — và cách chúng cộng dồn khi bạn quản lý nhiều cửa hàng — là điều thiết yếu để giữ cho đơn hàng chảy đều, tồn kho đồng bộ và mọi vận hành trơn tru.

Cơ chế giới hạn của REST API Shopify

REST Admin API của Shopify dùng thuật toán leaky bucket (xô rò rỉ) để quản lý dung lượng request. Hãy hình dung nó như một chiếc xô: mỗi lần gọi API là đổ thêm nước vào, và nước rò ra ngoài đều đặn theo thời gian.

Cơ chế cụ thể như sau:

Shopify trả về header X-Shopify-Shop-Api-Call-Limit: 32/40 trong phản hồi, cho biết mức sử dụng hiện tại so với dung lượng còn lại.

Vấn đề khi có nhiều cửa hàng: Khi quản lý 30 cửa hàng, bạn có 30 chiếc xô riêng biệt — mỗi cửa hàng một xô cho mỗi app. Nếu các worker chạy nền của bạn đồng thời đồng bộ tồn kho, kéo đơn hàng hay cập nhật sản phẩm trên cả 30 cửa hàng, bạn có thể làm cạn cả 30 chiếc xô cùng lúc và bị throttling trên toàn bộ hệ thống, dù từng cửa hàng vẫn nằm trong giới hạn riêng của nó.

GraphQL Admin API: Giới hạn dựa trên chi phí truy vấn

GraphQL Admin API của Shopify dùng một mô hình khác: chi phí truy vấn (query cost). Thay vì đếm từng request riêng lẻ, mỗi truy vấn được gán một mức chi phí dựa trên độ phức tạp và lượng dữ liệu mà nó yêu cầu.

Nguyên tắc cơ bản của mô hình chi phí:

Giới hạn theo từng gói:

Một truy vấn đơn lẻ không thể vượt quá 1.000 điểm, bất kể bạn đang dùng gói nào. Sau khi truy vấn chạy xong, Shopify tính lại chi phí thực tế và hoàn lại số điểm chưa dùng vào xô của bạn.

Vì sao điều này quan trọng với app đa cửa hàng: Một truy vấn tốn 50 điểm ở cửa hàng này thì vẫn tốn 50 điểm ở cửa hàng khác. Nếu bạn chạy cùng một bộ báo cáo, đồng bộ hay thao tác hàng loạt trên 20 cửa hàng, bạn sẽ ngốn hết lượng điểm mỗi giây rất nhanh. Với số điểm hạn chế, bạn buộc phải hoặc điều tiết request, hoặc trải đều chúng theo thời gian, hoặc dùng bulk operations để bỏ qua hoàn toàn giới hạn của từng truy vấn.

Bulk Operations: Lối thoát khỏi giới hạn rate-limit

Bulk operations được thiết kế để xử lý khối lượng dữ liệu lớn mà không chạm trần chi phí của một truy vấn đơn lẻ. Chúng không bị tính vào giới hạn rate-limit mỗi giây theo cách thông thường — thay vào đó, chúng được xếp hàng xử lý bất đồng bộ và chạy ngầm ở chế độ nền.

Từ phiên bản API 2026-01, bạn có thể chạy tối đa năm bulk mutation đồng thời trên mỗi cửa hàng. Trước 2026, bạn chỉ chạy được một thao tác mỗi lần. Đây là thay đổi đáng kể cho người vận hành nhiều cửa hàng: bạn có thể xếp hàng các tác vụ cập nhật, đồng bộ hay nhập dữ liệu hàng loạt trên nhiều cửa hàng mà không phải xử lý tuần tự từng cái một.

Bulk operations phải hoàn tất trong vòng 10 ngày. Nếu bạn đang đồng bộ sản phẩm, khách hàng hay đơn hàng trên hàng chục cửa hàng, bulk operations cho phép bạn bắn request đi mà không phải lo bị rate-limit phản đòn ngay lập tức.

Thách thức thực tế khi quản lý nhiều cửa hàng và cách giải quyết

Khi bạn vận hành một nền tảng quản lý 10, 50 hay thậm chí 150 cửa hàng, giới hạn API trở thành nút thắt cổ chai trong vận hành. Lý do là:

Vấn đề tải tích lũy: 30 worker chạy nền cùng gọi API Shopify song song trên 30 cửa hàng có thể làm cạn toàn bộ hạn mức gần như ngay tức khắc. Một worker cho mỗi cửa hàng, mỗi cái kéo đơn hàng hoặc đồng bộ tồn kho, cộng lại là 30 request trải trên 30 chiếc xô riêng biệt. Nếu xét riêng lẻ thì không sao. Nhưng khi cần phối hợp xuyên cửa hàng — kéo đơn từ cả 30, rồi cập nhật tồn kho trên cả 30, rồi đẩy sang hệ thống vận hành của bạn — thì cần điều phối rất cẩn thận.

Giải pháp: Triển khai một hệ thống backoff và hàng đợi (queue). Khi hạn mức API của một cửa hàng cạn kiệt:

  1. Ngừng gọi đến cửa hàng đó trong vài giây.
  2. Điều hướng worker sang các cửa hàng khác mà xô vẫn còn dung lượng.
  3. Tiếp tục hàng đợi của cửa hàng đó khi xô leaky bucket đã rò bớt đủ để nhận request mới.

Ngoài ra, hãy cân nhắc:

Chọn REST hay GraphQL cho vận hành đa cửa hàng

REST API đơn giản hơn để hiểu và triển khai. Cơ chế xô và tốc độ rò dễ dự đoán. Nó phù hợp với những thao tác đơn giản, nhẹ nhàng như kéo đơn hàng hoặc cập nhật trạng thái đơn.

GraphQL linh hoạt hơn và cho phép bạn lấy đúng những gì cần trong một request duy nhất. Truy vấn phức tạp có thể giảm số lần phải đi vòng (round-trip). Tuy nhiên, chi phí truy vấn đòi hỏi bạn phải lên kế hoạch và kiểm thử kỹ hơn để tránh bất ngờ.

Với nền tảng đa cửa hàng, GraphQL thường thắng thế vì bạn có thể lấy dữ liệu liên quan (đơn hàng, dòng sản phẩm, thông tin khách hàng) trong một truy vấn duy nhất thay vì phải gọi REST ba lần. Một truy vấn GraphQL được tối ưu tốt có thể tốn chi phí ngang ba request REST nhưng hoàn tất nhanh hơn và sử dụng hạn mức của bạn một cách dễ dự đoán hơn.

Vì sao điều này quan trọng với người dùng StoreFleet

StoreFleet quản lý toàn bộ hoạt động đa cửa hàng của bạn từ một dashboard duy nhất — đơn hàng, doanh thu, vận chuyển và tài chính trên tất cả cửa hàng. Để làm được điều đó một cách đáng tin cậy, chúng tôi đã xây dựng các API có nhận thức về rate-limit, giúp:

Nếu bạn đang quản lý 10 cửa hàng theo cách thủ công trong các tab Shopify admin riêng biệt, bạn đang tự nhân lên độ phức tạp trong vận hành của mình. Một nền tảng đa cửa hàng hợp nhất sẽ lo việc điều phối rate-limit thay cho bạn, để bạn tập trung phát triển cửa hàng thay vì gỡ lỗi API.

Muốn xem cách StoreFleet xử lý rate-limit và đồng bộ trên các cửa hàng của bạn? Dùng thử bản demo miễn phí ngay trên tài khoản Shopify của chính bạn. Chỉ cần liên hệ qua [email protected] hoặc đặt lịch demo trên trang chủ của chúng tôi.

Nguồn

Quản lý hàng chục store Shopify trên một dashboard

Đặt demo miễn phí trên chính store của bạn — xem số liệu thật trong vài phút.

Nhận demo →