ConnectWiz + API & Webhooks
Tích hợp đang hoạt độngAPI chúng tôi bán chính là API chúng tôi dùng
Toàn bộ nền tảng được đặc tả trong một hợp đồng OpenAPI duy nhất, và chính bảng quản trị lẫn ứng dụng di động của chúng tôi được sinh ra từ đó — không có endpoint ẩn, không có tài liệu lệch pha. Trên nền đó: khóa Commerce API có scope, trigger webhook đã bảo vệ, và những flow gọi sang hệ thống của bạn.
Nhà phát triển
Nó làm gì — chính xác
Một hợp đồng làm chuẩn
Một tài liệu OpenAPI 3 duy nhất đặc tả cả nền tảng; chính các client TypeScript của chúng tôi được sinh ra từ nó — tài liệu không thể lệch khỏi thực tế, vì thực tế được dựng ra từ tài liệu.
Khóa Commerce API
Khóa do từng tenant cấp với scope khai báo rõ — đọc danh mục sản phẩm, đọc đơn hàng, ghi đơn hàng — chạy storefront hay ứng dụng của riêng bạn trên cùng một bộ máy đơn hàng, và giá thì luôn được tính ở phía máy chủ.
Webhook vào, đã được bảo vệ
Mỗi trigger webhook của flow đều có URL và secret riêng, có xác thực HMAC trên phần body thô và có chống phát lại. Payload có thể nêu tên một người; nó không bao giờ lái được phần bên trong của flow.
Chiều ra đi qua Flows
Bước REST gọi sang hệ thống của bạn đúng vào những thời điểm bạn vẽ ra trên canvas — đơn được đặt, sự đồng ý được cấp, lịch được chốt.
Kỹ thuật bên trong
Những quan điểm thiết kế API, nói rõ
Giá không bao giờ đến từ phía client
Một yêu cầu đặt hàng chỉ nói món gì và mấy cái — tên và giá được đọc từ danh mục sản phẩm ngay lúc đó, ở phía máy chủ, rồi ghi vào dòng hàng như một bản chụp. Một yêu cầu bị sửa không thể bịa ra khuyến mãi.
Khai báo khả năng trước khi gọi
Mỗi phạm vi tích hợp đều công bố một cam kết về khả năng — nó khớp được theo số điện thoại không, liệt kê được đơn của khách vãng lai không, tạo được đơn không? — và gọi vượt qua một chữ "không" đã khai báo thì lỗi bật ra ngay, thay vì hỏng ở đâu đó rất sâu.
Lỗi nói lên điều gì đó
Tầng truyền tải phân biệt "không có quyền" với "dịch vụ đang chết" — nên "không với tới cửa hàng" không bao giờ bị hiển thị thành "khách này chưa từng mua gì". Lỗi có tên chính là khác biệt giữa một API và một trò đoán mò.
Webhook chống phát lại
Mỗi sự kiện chiều vào đều phải giành một khóa duy nhất trong sổ cái idempotency trước khi được xử lý — một lượt gửi thử lại hay phát lại chết ngay ở tầng cơ sở dữ liệu, không phải trong quy trình tự động hóa của bạn.
Khóa được băm, secret có scope
Khóa API được lưu dưới dạng băm, và ở cửa vào chỉ tra được đúng phần băm cùng scope — một dòng cơ sở dữ liệu bị lộ không nêu tên workspace nào và không mở được gì ngoài phạm vi scope của nó.
Nháp và xác nhận đều phải nói rõ
Việc tạo đơn nhận một tham số confirm khai báo rõ — API công khai mặc định là đã xác nhận, còn luồng trong bảng quản trị thì dựng được đơn nháp — nên "cái này có thật không?" là một trường dữ liệu, không phải một quy ước ngầm.
Thiết lập
Cách nó kết nối
Cấp một khóa
Tạo một khóa Commerce API có scope trong bảng quản trị; thu hồi cũng dễ y như vậy.
Đấu một webhook
Tạo một flow có trigger webhook; ký các request bằng secret của nó.
Gọi ngược ra ngoài
Thêm bước REST ở đúng chỗ mà hệ thống của bạn cần nghe tin.
Kết hợp thì hơn
Nó kết hợp với những gì
Flows
Trigger webhook khởi động các flow; bước REST gọi ngược về hệ thống của bạn đúng những thời điểm bạn vẽ ra — tự động hóa chiều vào và chiều ra dùng chung một canvas.
Thương mại
Chính bộ máy danh mục sản phẩm và đơn hàng nằm sau API cũng là bộ máy mà cửa hàng trong chat và AI dùng — một sự thật đơn hàng duy nhất, bốn cái cửa.
Storefront của riêng bạn
Nhiều đội đang chạy storefront headless trên Commerce API ngay hôm nay — chính con đường mà trang Shopify thành thật khuyên dùng trong lúc trình kết nối gốc còn đang được dựng.
Bảo mật & cam kết
Những cam kết nhàm chán
HMAC trên phần body thô
Việc xác thực webhook ký phần body thô của request bằng secret riêng của từng trigger và so sánh trong thời gian hằng số — chỉ sau khi có bằng chứng mới tới lượt phân tích nội dung.
Payload là dữ liệu, không bao giờ là mệnh lệnh
Payload của webhook có thể trỏ tới một người; nó không bao giờ lái được phần bên trong của flow, không viết lại prompt và không gọi được công cụ. Ranh giới giữa dữ liệu và mệnh lệnh nằm trong kiến trúc, không phải trong hành vi.
Giới hạn tần suất ở mọi cửa
Endpoint công khai chạy trên cơ chế tiết lưu tiêu chuẩn, và giới hạn đọc bị chặn ở phía máy chủ — một client cư xử tệ chỉ tự làm mình chậm đi, không kéo cả nền tảng theo.
Điều khoản nhỏ, nói thật
Giới hạn, nói rõ
Chưa có vòi phun sự kiện
Một luồng webhook kiểu đăng ký nhận tất tần tật thì chưa dựng — hôm nay sự kiện chiều ra đi qua các bước trong flow. Nói rõ ở đây, để không cuộc gọi bán hàng nào phải ám chỉ điều ngược lại.
Đọc có giới hạn, do thiết kế
Mỗi lượt đọc trả về tối đa 100 bản ghi kèm con trỏ phân trang — API này dựng cho tích hợp vận hành, không phải để xuất hàng loạt. Nhu cầu xuất hàng loạt là chuyện để trao đổi, không phải một kẽ hở.
Kết nối thành thật hơn kết nối ồn ào.
Mọi tích hợp ở đây được mô tả bằng đúng những gì nó làm — kèm chiều dữ liệu, quyền sở hữu và giới hạn.