מה API להזמנת מלונות צריך לתמוך בו?

מחירים וזמינות חיים, יצירת הזמנה, תשלום, ואישור עם webhooks. APIs של תוכן לקריאה בלבד מכסים רק את הראשון ואינם יכולים להשלים עסקה.

האם ה-API של Wink חינמי לשימוש?

ה-Consumer וה-Booking Engine APIs חינמיים. ה-Partner API כולל 10,000 לילות חינם בחודש, ואז מחייב לפי יחידה.

האם אני חייב להיות הסוחר הרשום?

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

האם סוכני AI יכולים להזמין דרך אותן היכולות?

כן. שרת MCP חושף חיפוש, תמחור והזמנה לסוכנים, כך שסייע יכול להשלים הזמנה במקום להפנות את המשתמש לאתר.

איך אני מקבל תשלום כממשק אינטגרציה?

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

האם אני צריך לבנות ממשק משתמש?

לא בהכרח. רכיבי ווב מספקים חיפוש שניתן להזמין, רשימות חדרים ותשלום שניתן להטמיע בדף קיים; ה-REST API קיים כשזרימת ההזמנה צריכה להיות שלך.

API להזמנת מלונות — איך להוסיף הזמנת מלון למוצר

ארבע היכולות החשובות

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

רוב “API למלונות” שמפתח מוצא מכסים את הראשון ולפעמים את השני. העסקה היא החלק הקשה, וזה החלק שמכריע אם יש לך מוצר.

של מי המלאי שאתה משלב?

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

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

מי הסוחר הרשום

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

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

שלושה רמות של אינטגרציה

רכיבי ווב. טוענים חיפוש שניתן להזמין, רשימת חדרים או תשלום בדף קיים. אין צורך בעבודה ב-backend; שליטה מינימלית על העיצוב.
REST API. שליטה מלאה על חיפוש, מחירים, יצירת הזמנה ואישור, מאומת עם OAuth2. משתמשים בו כשהזרימה היא חלק מחוויית המוצר שלך.
שרת MCP. אותן היכולות נחשפות לסוכני AI, כך שסייע יכול לחפש, לתמחר ולהשלים הזמנה במקום להפנות את המשתמש לאתר.

שלושתם לא בלעדיים — מוצר בדרך כלל משתמש ברכיבים לממשק שיווקי וב-API לזרימה המרכזית שלו.

מה לבנות קודם

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

תמחור שמפתח צריך לדעת

ה-Consumer וה-Booking Engine APIs חינמיים. ה-Partner API כולל הקצבה חודשית חינמית של 10,000 לילות במלון, ואז מחייב לפי יחידה. הזמנות מאושרות נושאות את דמי הפלטפורמה של המלון בגובה 1.5% בתוספת עלות עיבוד כרטיס, ו10% עמלת ברירת מחדל חלה כשהמוצר שלך הוביל להזמנה — כך שממשק אינטגרציה מרוויח במקום לשלם.

טעויות נפוצות

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

איך מפתחים מוסיפים הזמנת מלון למוצר?