ConnectWiz + API ו-Webhooks

אינטגרציה פעילה

ה-API שאנחנו מוכרים הוא ה-API שאנחנו משתמשים בו

כל הפלטפורמה מוגדרת בחוזה OpenAPI אחד שממנו נוצרים הפאנל שלנו ואפליקציית המובייל — בלי נקודות קצה נסתרות, בלי סטייה בתיעוד. מעליו: מפתחות Commerce API עם היקף, טריגרים מאובטחים של webhook, ותהליכים שמתקשרים למערכות שלכם.

חוזה OpenAPI אחד מפתחות API עם היקף webhooks מאומתים ב-HMAC
API ו-Webhooks × ConnectWiz
מטענים הם נתונים, לעולם לא פקודות
מפתח עם היקף: קריאת קטלוג · כתיבת הזמנות
webhook ← אומת ב-HMAC ← התהליך מתחיל
שלב REST בתהליך קורא ל-API שלכם
1
חוזה OpenAPI מחייב — אותו קובץ שממנו נוצרים הפאנל ואפליקציות המובייל שלנו
3
היקפי Commerce — קריאת קטלוג, קריאת הזמנות, כתיבת הזמנות — מונפקים לכל מפתח
100
מקסימום שורות לכל קריאה, מוגבל בצד השרת — פרמטר ההגבלה עובר ולידציה, לעולם לא סומכים עליו
50
שורות פריט להזמנה דרך ה-API — גבול מוצהר, לא כזה שמתגלים אליו בדרך הקשה

מפתחים

מה זה עושה, בדיוק

חוזה מחייב אחד

מסמך OpenAPI 3 יחיד מגדיר את הפלטפורמה; לקוחות ה-TypeScript שלנו נוצרים ממנו — התיעוד לא יכול לסטות מהמציאות, כי המציאות נבנית מהתיעוד.

מפתחות Commerce API

מפתחות שמנפיק הלקוח עם היקפים מפורשים — קריאת קטלוג, קריאת הזמנות, כתיבת הזמנות — מפעילים חנות או אפליקציה משלכם על אותו מנוע הזמנות, כשהמחירים תמיד נפתרים בצד השרת.

webhooks נכנסים, מאובטחים

לכל טריגר webhook בתהליך יש URL וסוד משלו, אימות HMAC על גוף הבקשה הגולמי והגנה מפני שידור חוזר. מטען יכול לנקוב בשם של אדם; הוא לעולם לא יכול לכוון את הפנימיות של התהליך.

יוצא דרך תהליכים

שלב ה-REST קורא למערכות שלכם בדיוק ברגעים שאתם מציירים על הקנבס — הזמנה בוצעה, הסכמה ניתנה, תור נקבע.

הצד הטכני

עמדות בתכנון ה-API, כתובות

מחירים לעולם לא מגיעים מהלקוח

בקשת הזמנה אומרת מה וכמה — השם והמחיר נקראים מהקטלוג באותו רגע, בצד השרת, ונכתבים על השורה כתצלום מצב. בקשה שעברה מניפולציה לא יכולה להמציא הנחה.

יכולות לפני קריאות

כל משטח אינטגרציה מפרסם חוזה יכולות — האם הוא יודע להתאים לפי טלפון, להציג הזמנות אורח, ליצור הזמנות? — וקריאה מעבר לתשובת "לא" מוצהרת זורקת שגיאה מיד, במקום להיכשל אי שם בעומק.

שגיאות שאומרות משהו

השכבה מבדילה בין "לא מורשה" לבין "השירות מושבת" — כך שהמשפט "החנות לא נגישה" לעולם לא מוצג בתור "הלקוח הזה מעולם לא קנה כלום". שגיאות עם שם הן ההבדל בין API לבין משחק ניחושים.

webhooks חסינים לשידור חוזר

כל אירוע נכנס תופס מפתח ייחודי בספר רישום של אי-כפילות לפני העיבוד — מסירה חוזרת או משודרת מחדש מתה בשכבת מסד הנתונים, לא בתוך האוטומציה שלכם.

מפתחות בגיבוב, סודות עם היקף

מפתחות API נשמרים כגיבוב, וליד הדלת ניתן לפענח רק את הגיבוב ואת ההיקפים — שורה שדלפה ממסד הנתונים לא נוקבת בשם סביבת עבודה ולא פותחת דבר מעבר להיקפים שלה.

טיוטות ואישורים הם מפורשים

יצירת הזמנה מקבלת פרמטר אישור מפורש — ה-API הציבורי מוגדר כברירת מחדל למאושר, ותהליכי הפאנל יכולים להכין טיוטות — כך שהשאלה "האם זה אמיתי?" היא שדה, לא מוסכמה.

הגדרה

איך זה מתחבר

01

הנפיקו מפתח

צרו מפתח Commerce API עם היקף בפאנל; בטלו אותו באותה קלות.

02

חברו webhook

צרו תהליך עם טריגר webhook; חתמו את הבקשות עם הסוד שלו.

03

קראו בחזרה החוצה

הוסיפו שלבי REST במקומות שבהם המערכות שלכם צריכות לשמוע על זה.

טובים יחד

עם מה זה משתלב

Flows

טריגרים של webhook מתחילים תהליכים; שלבי REST מתקשרים בחזרה למערכות שלכם ברגעים שאתם מציירים — אוטומציה נכנסת ויוצאת חולקות קנבס אחד.

Commerce

הרי מנוע הקטלוג וההזמנות שמאחורי ה-API הוא אותו מנוע שחנות הצ'אט והבינה המלאכותית משתמשות בו — אמת הזמנה אחת, ארבע דלתות.

חנות משלכם

צוותים מריצים היום חנויות headless על Commerce API — זו הדרך שעליה ממליץ בכנות עמוד Shopify בזמן שהמחבר הייעודי נבנה.

אבטחה והבטחות

ההבטחות המשעממות

HMAC על הגוף הגולמי

אימות ה-webhook חותם את גוף הבקשה הגולמי בסוד ייעודי לטריגר ומשווה בזמן קבוע — הפענוח קורה רק אחרי ההוכחה.

מטענים הם נתונים, לעולם לא פקודות

מטען של webhook יכול להפנות לאדם; הוא לעולם לא יכול לכוון את הפנימיות של תהליך, לשכתב הנחיות או להפעיל כלים. הגבול בין נתונים להוראות הוא ארכיטקטוני, לא התנהגותי.

מגבלות קצב בכל דלת

נקודות קצה ציבוריות רוכבות על ויסות סטנדרטי, ומגבלות הקריאה מוגבלות בצד השרת — לקוח שמתנהג רע פוגע בעצמו, לא בפלטפורמה.

האותיות הקטנות, בלי קישוטים

גבולות, כתובים

עוד אין זרנוק

פיד webhook גנרי שמנוי על הכול לא נבנה — אירועים יוצאים קורים היום דרך שלבי תהליך. כתוב כאן, כדי ששום שיחת מכירה לא תצטרך לרמוז אחרת.

קריאות מוגבלות, מתוך תכנון

קריאות מחזירות עד 100 שורות עם סמן — ה-API נבנה לאינטגרציה תפעולית, לא לייצוא המוני. צורכי ייצוא המוני הם שיחה, לא פרצה.

שאלות נפוצות על API ו-Webhooks

תשובות ישירות

מידע נוסף בעמוד שאלות נפוצות, או פנו אלינו ישירות.

הפלטפורמה מוגדרת בחוזה OpenAPI 3 אחד — אותו קובץ שממנו הפאנל שלנו ואפליקציית המובייל מייצרים את הטיפוסים שלהם. מה שאתם משתלבים מולו הוא מה שאנחנו מריצים.

סודות לכל טריגר, אימות HMAC על הגוף הגולמי, והגנה מפני שידור חוזר דרך ספר רישום של אי-כפילות. וכעיקרון, המטענים הם נתונים: הם יכולים להפנות לאדם, לעולם לא לפקד על האוטומציה.

דרך שלבי REST בתהליכים, שנורים ברגעים שאתם בוחרים על הקנבס. פיד webhook יוצא גנרי נמצא במפת הדרכים ובמכוון לא מובטח עד שיגיע.

כן — קריאות קטלוג וכתיבת הזמנות הן הדרך הנתמכת, כשהמחירים נפתרים בצד השרת ויש מפתחות עם היקף שאפשר לבטל לכל משטח. הגבולות של 50 שורות ושל 100 רשומות כתובים כדי שתתכננו מולם במקום להיתקל בהם.

המסירות אידמפוטנטיות מהצד שלנו — ספר הרישום מזהה שידור חוזר ומפיל אותו, כך שהמערכות שלכם יכולות לנסות שוב בבטחה. שלבי REST יוצאים מתוך תהליכים נושאים מדיניות ניסיון חוזר משלהם, וכשלים מוצגים על הרצת התהליך.

חיבור כן עדיף על חיבור רועש.

כל אינטגרציה כאן מתוארת לפי מה שהיא באמת עושה — כיוון, בעלות ומגבלות כלולים.