ConnectWiz + API & Webhooks

การเชื่อมต่อที่ใช้งานจริง

API ที่เราขายคือ API ที่เราใช้เอง

ทั้งแพลตฟอร์มถูกกำหนดไว้ในสัญญา OpenAPI ฉบับเดียว ซึ่งแผงควบคุมและแอปมือถือของเราเองถูกสร้างขึ้นมาจากมัน — ไม่มี endpoint เงา ไม่มีเอกสารที่เพี้ยนจากของจริง และบนนั้นยังมี: คีย์ Commerce API ที่มีขอบเขตจำกัด ทริกเกอร์ webhook ที่มีการป้องกัน และโฟลว์ที่เรียกกลับไปยังระบบของคุณ

เริ่มใช้ฟรี การเชื่อมต่อทั้งหมด
สัญญา OpenAPI ฉบับเดียว คีย์ API ที่มีขอบเขตจำกัด webhook ที่ตรวจด้วย HMAC
API & Webhooks × ConnectWiz
payload คือข้อมูล ไม่ใช่คำสั่ง
คีย์ที่มีขอบเขต: อ่านแคตตาล็อก · เขียนออเดอร์
webhook → ตรวจ HMAC ผ่าน → โฟลว์เริ่มทำงาน
REST step ในโฟลว์เรียก API ของคุณ
1
สัญญา OpenAPI ที่ถือเป็นฉบับจริง — ไฟล์เดียวกับที่แผงควบคุมและแอปมือถือของเราสร้างตัวเองขึ้นมา
3
scope ฝั่งคอมเมิร์ซ — อ่านแคตตาล็อก อ่านออเดอร์ เขียนออเดอร์ — ออกให้แยกทีละคีย์
100
จำนวนแถวสูงสุดต่อการอ่านหนึ่งครั้ง จำกัดไว้ฝั่งเซิร์ฟเวอร์ — พารามิเตอร์ limit ถูกตรวจสอบ ไม่ใช่เชื่อใจ
50
รายการสินค้าต่อหนึ่งออเดอร์ผ่าน API — ขอบเขตที่บอกไว้ล่วงหน้า ไม่ใช่ให้ไปเจอเอง

นักพัฒนา

ทำอะไรได้บ้าง — แบบเจาะจง

สัญญาฉบับจริงเพียงฉบับเดียว

เอกสาร OpenAPI 3 ฉบับเดียวกำหนดทั้งแพลตฟอร์ม และไคลเอนต์ TypeScript ของเราเองก็สร้างขึ้นมาจากมัน — เอกสารจึงเพี้ยนไปจากของจริงไม่ได้ เพราะของจริงสร้างมาจากเอกสาร

คีย์ Commerce API

คีย์ที่ออกให้แต่ละ tenant พร้อม scope ที่ระบุไว้ชัด — อ่านแคตตาล็อก อ่านออเดอร์ เขียนออเดอร์ — ขับเคลื่อนหน้าร้านหรือแอปของคุณเองบนเอนจินออเดอร์ตัวเดียวกัน โดยราคาถูกคำนวณฝั่งเซิร์ฟเวอร์เสมอ

webhook ขาเข้า ป้องกันไว้แล้ว

ทริกเกอร์ webhook ของทุกโฟลว์มี URL และ secret ของตัวเอง มีการตรวจ HMAC บน raw body และมีการป้องกันการส่งซ้ำ payload ระบุชื่อคนได้ แต่ไม่มีวันบังคับทิศทางภายในของโฟลว์ได้

ขาออกผ่านโฟลว์

REST step เรียกระบบของคุณในจังหวะที่คุณวาดไว้บนแคนวาสเป๊ะ ๆ — ตอนมีออเดอร์ ตอนได้รับความยินยอม ตอนมีการจอง

เบื้องหลังการทำงาน

จุดยืนในการออกแบบ API ที่ประกาศไว้

ราคาไม่เคยมาจากฝั่งไคลเอนต์

คำขอสร้างออเดอร์บอกแค่ว่าอะไรและกี่ชิ้น — ชื่อและราคาถูกอ่านจากแคตตาล็อก ณ วินาทีนั้นบนเซิร์ฟเวอร์ แล้วเขียนลงบนรายการเป็นสแนปช็อต คำขอที่ถูกแก้ไขจึงเสกส่วนลดขึ้นมาเองไม่ได้

ถามความสามารถก่อนเรียกใช้

จุดเชื่อมต่อแต่ละจุดประกาศสัญญาความสามารถของตัวเอง — จับคู่ด้วยเบอร์โทรได้ไหม ดูออเดอร์ของผู้ซื้อที่ไม่ได้สมัครสมาชิกได้ไหม สร้างออเดอร์ได้ไหม — และการเรียกข้าม "ไม่ได้" ที่ประกาศไว้จะโยนข้อผิดพลาดทันที แทนที่จะไปพังลึก ๆ อยู่ข้างใน

ข้อผิดพลาดที่มีความหมาย

ชั้นขนส่งข้อมูลแยก "ไม่มีสิทธิ์" ออกจาก "บริการล่ม" — "ติดต่อร้านไม่ได้" จึงไม่มีวันถูกแปลงเป็น "ลูกค้าคนนี้ไม่เคยซื้ออะไรเลย" ข้อผิดพลาดที่ระบุชื่อไว้คือเส้นแบ่งระหว่าง API กับเกมทายใจ

webhook ที่ส่งซ้ำแล้วไม่ซ้ำ

ทุกอีเวนต์ขาเข้าต้องจองคีย์เฉพาะในบัญชีบันทึก idempotency ก่อนจะถูกประมวลผล — การส่งซ้ำหรือการส่งย้อนจึงตายตั้งแต่ชั้นฐานข้อมูล ไม่ใช่ไปตายในระบบอัตโนมัติของคุณ

คีย์ถูกแฮช secret ถูกจำกัดขอบเขต

คีย์ API ถูกเก็บเป็นค่าแฮช และที่หน้าประตูอ่านได้แค่ค่าแฮชกับ scope เท่านั้น — แถวฐานข้อมูลที่หลุดออกไปจึงไม่ได้บอกว่าเป็น workspace ไหน และปลดล็อกอะไรเกิน scope ของมันไม่ได้

ร่างกับการยืนยันแยกกันชัดเจน

การสร้างออเดอร์รับพารามิเตอร์ confirm อย่างชัดเจน — API สาธารณะตั้งค่าเริ่มต้นเป็นยืนยันแล้ว ส่วนโฟลว์ในแผงควบคุมพักเป็นร่างไว้ได้ — คำถามว่า "อันนี้ของจริงหรือเปล่า" จึงเป็นฟิลด์ ไม่ใช่ธรรมเนียมที่ต้องเดา

การตั้งค่า

เชื่อมต่ออย่างไร

01

ออกคีย์

สร้างคีย์ Commerce API ที่มีขอบเขตจำกัดในแผงควบคุม และเพิกถอนได้ง่ายพอกัน

02

ต่อ webhook

สร้างโฟลว์ที่มีทริกเกอร์ webhook แล้วเซ็นคำขอด้วย secret ของมัน

03

เรียกกลับออกไป

เพิ่ม REST step ตรงจุดที่ระบบของคุณต้องรู้เรื่อง

ใช้ร่วมกันแล้วดีกว่า

ประกอบเข้ากับอะไรได้บ้าง

Flows

สิ่งที่ทริกเกอร์ webhook เริ่มต้นให้คือ โฟลว์; ส่วน REST step ก็เรียกกลับไปยังระบบของคุณในจังหวะที่คุณวาดไว้ — ระบบอัตโนมัติขาเข้าและขาออกใช้แคนวาสเดียวกัน

คอมเมิร์ซ

เบื้องหลัง API คือ เอนจินแคตตาล็อกและออเดอร์ และเป็นตัวเดียวกับที่ร้านค้าในแชทและ AI ใช้ — ความจริงเรื่องออเดอร์ชุดเดียว สี่ประตู

หน้าร้านของคุณเอง

หลายทีมรันหน้าร้านแบบ headless บน Commerce API อยู่แล้ววันนี้ — และหน้าที่แนะนำเส้นทางนี้ไว้ตรงไปตรงมาคือ หน้า Shopify ระหว่างที่คอนเนกเตอร์แบบเนทีฟยังสร้างไม่เสร็จ

ความปลอดภัยและการรับประกัน

การรับประกันที่น่าเบื่อ

HMAC บน raw body

การตรวจสอบ webhook เซ็น raw body ของคำขอด้วย secret แยกรายทริกเกอร์ แล้วเทียบแบบ constant time — การแกะข้อมูลเกิดขึ้นหลังพิสูจน์ได้แล้วเท่านั้น

payload คือข้อมูล ไม่ใช่คำสั่ง

payload ของ webhook อ้างถึงคนคนหนึ่งได้ แต่ไม่มีวันบังคับทิศทางภายในของโฟลว์ เขียนพรอมป์ทับ หรือสั่งเรียกเครื่องมือได้ เส้นแบ่งระหว่างข้อมูลกับคำสั่งอยู่ที่สถาปัตยกรรม ไม่ใช่ที่พฤติกรรม

จำกัดอัตราที่ทุกประตู

endpoint สาธารณะอยู่ภายใต้การจำกัดอัตรามาตรฐาน และเพดานการอ่านถูกบีบไว้ฝั่งเซิร์ฟเวอร์ — ไคลเอนต์ที่ทำตัวไม่ดีจะทำให้ตัวเองช้าลง ไม่ใช่ทั้งแพลตฟอร์ม

เงื่อนไขปลีกย่อยแบบพูดตรง

ขอบเขตที่ระบุไว้ชัดเจน

ยังไม่มีฟีดแบบ firehose

ฟีด webhook แบบสมัครรับทุกอย่างยังไม่ได้สร้าง — อีเวนต์ขาออกวันนี้เกิดผ่านสเต็ปในโฟลว์ เราเขียนไว้ตรงนี้ จะได้ไม่มีการโทรขายไหนต้องพูดเป็นอย่างอื่น

การอ่านที่มีเพดาน ตั้งใจออกแบบมาแบบนั้น

การอ่านคืนค่าได้สูงสุด 100 แถวพร้อมการไล่ด้วยเคอร์เซอร์ — API นี้สร้างมาเพื่อการเชื่อมต่อเชิงปฏิบัติการ ไม่ใช่การดึงข้อมูลก้อนใหญ่ ถ้าต้องการดึงก้อนใหญ่ ให้คุยกัน ไม่ใช่หาช่องโหว่

FAQ เรื่อง API & Webhooks

คำตอบตรงไปตรงมา

อ่านเพิ่มเติมได้ที่หน้า FAQ หรือ ถามเราโดยตรง.

แพลตฟอร์มถูกกำหนดไว้ในสัญญา OpenAPI 3 ฉบับเดียว — ไฟล์เดียวกับที่แผงควบคุมบนเว็บและแอปมือถือของเราสร้างชนิดข้อมูลขึ้นมา สิ่งที่คุณเชื่อมต่อด้วยคือสิ่งเดียวกับที่เรารันอยู่

secret แยกรายทริกเกอร์ การตรวจ HMAC บน raw body และการป้องกันการส่งซ้ำผ่านบัญชีบันทึก idempotency และตามกฎแล้ว payload คือข้อมูล: มันอ้างถึงคนคนหนึ่งได้ แต่สั่งงานระบบอัตโนมัติไม่ได้

ผ่าน REST step ในโฟลว์ ยิงในจังหวะที่คุณเลือกไว้บนแคนวาส ส่วนฟีด webhook ขาออกแบบทั่วไปอยู่บนโรดแมป และเราตั้งใจไม่สัญญาอะไรจนกว่ามันจะออกจริง

ได้ — การอ่านแคตตาล็อกและการเขียนออเดอร์คือเส้นทางที่รองรับ โดยราคาถูกคำนวณฝั่งเซิร์ฟเวอร์ และคีย์ที่มีขอบเขตจำกัดก็เพิกถอนแยกตามจุดใช้งานได้ เพดาน 50 รายการและ 100 แถวถูกประกาศไว้ เพื่อให้คุณออกแบบรับมันตั้งแต่ต้น ไม่ใช่ไปสะดุดเอาทีหลัง

การส่งเป็น idempotent ในฝั่งเรา — บัญชีบันทึกจะรู้ทันการส่งซ้ำแล้วทิ้งมันไป ระบบของคุณจึงส่งใหม่ได้อย่างปลอดภัย ส่วน REST step ขาออกจากโฟลว์มีนโยบายการส่งซ้ำของตัวเอง และความล้มเหลวจะขึ้นให้เห็นบนการรันโฟลว์นั้น

เชื่อมต่ออย่างตรงไปตรงมา ดีกว่าเชื่อมต่ออย่างเอิกเกริก

การเชื่อมต่อทุกตัวที่นี่อธิบายด้วยสิ่งที่มันทำจริง — รวมถึงทิศทางข้อมูล สิทธิ์ความเป็นเจ้าของ และข้อจำกัด

เริ่มใช้ฟรี การเชื่อมต่อทั้งหมด