Mit kell támogatnia egy szállodai foglalási API-nak?

Élő árak és elérhetőség, foglalás létrehozása, fizetés, és megerősítés webhookokkal. Az olvasásra szolgáló tartalom API-k csak az elsőt fedik le, és nem tudnak tranzakciót befejezni.

Ingyenes a Wink API használata?

A Consumer és Booking Engine API-k ingyenesek. A Partner API havi 10 000 szállodai éjszakát tartalmaz ingyenesen, utána egységenként számláz.

Kell kereskedővé válnom?

Nem. A szálloda marad a kereskedő, és a fizetés a szálloda számára történik. Kereskedői megállapodások léteznek API integrációknál, ahol a partnernek valóban szüksége van a fizetés átvételére, saját engedélyezési követelményekkel.

Az AI ügynökök ugyanazokon a képességeken keresztül foglalhatnak?

Igen. Az MCP szerver keresést, árazást és foglalást tesz elérhetővé az ügynököknek, így egy asszisztens befejezheti a foglalást anélkül, hogy a felhasználót weboldalra irányítaná.

Hogyan kapok fizetést integrátorként?

10% alap jutalék vonatkozik azokra a foglalásokra, amelyeket a terméked generált, a szálloda platformdíja és a kártyakezelés után, az attribúció 6 hónapig tart kattintásonként.

Kell UI-t építenem?

Nem feltétlenül. A webkomponensek foglalható keresőt, szobalistákat és fizetési felületet biztosítanak, amelyeket egy meglévő oldalba lehet helyezni; a REST API akkor van, ha a folyamat a tiéd kell legyen.

Szállodai foglalási API — Hogyan adjunk szállodai foglalást egy termékhez

A négy fontos képesség

Képesség	Mit jelent	Miért akad el nélküle a termék
Élő árak és elérhetőség	Aktuális árak és mi foglalható ténylegesen, dátumtartományonként	A gyorsítótárazott árak megerősítéskor hibáznak és aláássák a bizalmat
Foglalás létrehozása	Valódi foglalás létrehozása, amit a szálloda megkap	Nélküle csak egy ajánló link vagy, nem termék
Fizetés	Pénz fogadása a foglalás részeként	Egy másik oldalra irányításnál elvész a konverzió
Megerősítés és webhookok	Tájékoztatni a vendéget, a szállodát és a rendszeredet, mi történt	Egyébként támogatási terhelés és egyeztetési hiányosságok lesznek

A legtöbb “szállodai API”, amit egy fejlesztő talál, az elsőt, néha a másodikat fedi le. A tranzakció a nehéz rész, és ez dönti el, hogy van-e terméked.

Kinek a kínálatát integrálod?

Ez a kérdés alakítja a továbbiakat. A láncon keresztül újraértékesített kínálat árrést tartalmaz az árban, elavultabb elérhetőséget, és nincs visszacsatolás a szállodához foglalási kérdés esetén. A közvetlenül a szállodától származó kínálat a szálloda saját árát, élő elérhetőséget és egy olyan szállodát jelent, amely tud a foglalásról.

Bármi esetén, amikor az utazó összehasonlítja a szálloda saját weboldalával — ami a legtöbb eset — a szálloda által kontrollált kínálat elkerüli azt a kínos pillanatot, amikor az ár rosszabb.

Ki a kereskedő

Ha te magad építed a szállodai foglalást, a kereskedővé válás azt jelenti, hogy vállalod a fizetési felelősséget, visszatérítéseket, adókezelést és gyakran utazási ügynöki engedélyt minden piacon.

A Wink-nál a szálloda marad a kereskedő, és a fizetés a szálloda számára történik, így az integrátornak nem kell ezt a terhet vállalnia. Kereskedői megállapodások elérhetők API integrációknál, ahol a partnernek valóban szüksége van a fizetés átvételére, és ez a megoldás saját engedélyezési követelményeket von maga után.

Három integrációs szint

Webkomponensek. Helyezz be egy foglalható keresőt, szobalistát vagy fizetési felületet egy meglévő oldalba. Nincs backend munka; legkevesebb irányítás a megjelenés felett.
REST API. Teljes irányítás a keresés, árak, foglalás létrehozása és megerősítés felett, OAuth2 hitelesítéssel. Használd, ha a foglalási folyamat a termék saját élményének része.
MCP szerver. Ugyanazokat a képességeket teszi elérhetővé AI ügynököknek, így egy asszisztens kereshet, árazhat és befejezhet egy foglalást anélkül, hogy a felhasználót weboldalra irányítaná.

A három nem kizárólagos — egy termék gyakran használ komponenseket marketing felületként és az API-t a fő folyamathoz.

Mit építs először

Keresés és ár egy városra és egy dátumtartományra. Szerezz valódi árakat mielőtt bármit terveznél.
Hozz létre egy tesztfoglalást végig, beleértve a fizetést és a megerősítést.
Iratkozz fel a booking.create és a lemondási eseményekre mielőtt bármilyen UI-t építenél rá.
Döntsd el korán az attribúciós modellt — a forrás kontextusnak utaznia kell a foglalással, különben később csak találgatás lesz a jelentés.
Kezeld a hibás eseteket: elérhetőség elvesztése az ajánlat és a foglalás között, elutasított fizetés, részleges visszatérítések.

Árazás, amit a fejlesztőnek tudnia kell

A Consumer és Booking Engine API-k ingyenesek. A Partner API havi 10 000 szállodai éjszaka ingyenes keretet tartalmaz, utána egységenként számláz. A megerősített foglalások a szálloda 1,5%-os platformdíját és a kártyakezelési költséget tartalmazzák, és 10% alap jutalék vonatkozik, ha a terméked vezette a foglalást — így az integrátor keres, nem fizet.

Gyakori hibák

Gyorsítótárazott árakra építeni. Fejlesztéskor jól néznek ki, de élesben hibáznak.
Fizetés átirányításra hagyása. Minden átadásnál veszteség van a foglalásokból.
Webhookok figyelmen kívül hagyása a bevezetésig. Az egyeztetés kézi munkává válik.
Kereskedővé válás szükségtelenül. Ez engedélyezési és felelősségi döntés, nem csak technikai.
Forrás kontextus át nem adása. Az attribúció később nem állítható helyre.

Hogyan adnak a fejlesztők szállodai foglalást egy termékhez?