ConnectWiz + API & Webhooks

Tích hợp đang hoạt động

API 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.

Một hợp đồng OpenAPI duy nhất Khóa API có scope Webhook xác thực bằng HMAC
API & Webhooks × ConnectWiz
Payload là dữ liệu, không bao giờ là mệnh lệnh
Khóa có scope: đọc danh mục sản phẩm · ghi đơn hàng
Webhook → xác thực HMAC → flow khởi động
Bước REST của flow gọi sang API của bạn
1
Hợp đồng OpenAPI làm chuẩn — đúng cái tệp mà bảng quản trị và ứng dụng di động của chúng tôi sinh ra từ đó
3
Scope thương mại — đọc danh mục sản phẩm, đọc đơn hàng, ghi đơn hàng — cấp theo từng khóa
100
Số bản ghi tối đa mỗi lượt đọc, chặn ở phía máy chủ — tham số limit được kiểm, không bao giờ được tin sẵn
50
Số dòng hàng mỗi đơn khi đi qua API — một giới hạn nói trước, không phải thứ bạn tự phát hiện ra

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

01

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.

02

Đấu một webhook

Tạo một flow có trigger webhook; ký các request bằng secret của nó.

03

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ở.

FAQ API & Webhooks

Trả lời thẳng

Xem thêm trong trang FAQ, hoặc hỏi thẳng chúng tôi.

Nền tảng được đặc tả trong một hợp đồng OpenAPI 3 duy nhất — đúng cái tệp mà bảng quản trị web và ứng dụng di động của chúng tôi sinh kiểu dữ liệu ra từ đó. Thứ bạn tích hợp vào chính là thứ chúng tôi đang chạy trên đó.

Secret riêng cho từng trigger, xác thực HMAC trên phần body thô, và chống phát lại bằng một sổ cái idempotency. Và theo nguyên tắc, payload là dữ liệu: chúng có thể trỏ tới một người, nhưng không bao giờ ra lệnh cho quy trình tự động hóa.

Được, qua bước REST trong flow, bắn đi đúng những thời điểm bạn chọn trên canvas. Một luồng webhook đi ra kiểu tổng quát thì nằm trong lộ trình và cố tình không được hứa trước khi nó ra mắt.

Được — đọc danh mục sản phẩm và ghi đơn hàng là con đường được hỗ trợ, với giá tính ở phía máy chủ và khóa có scope mà bạn thu hồi được theo từng nơi dùng. Giới hạn 50 dòng hàng mỗi đơn và 100 bản ghi mỗi lượt đọc được nói trước, để bạn thiết kế theo nó thay vì vấp phải nó.

Ở phía chúng tôi, mỗi lượt gửi đều idempotent — sổ cái nhận ra một lượt phát lại và bỏ nó đi, nên hệ thống của bạn cứ thử lại thoải mái. Bước REST chiều ra từ flow thì mang chính sách thử lại của riêng nó, và lỗi được hiện ngay trên lượt chạy của flow.

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.