重要な4つの機能
Section titled “重要な4つの機能”| 機能 | 意味 | これがないと製品が停滞する理由 |
|---|---|---|
| リアルタイムの料金と空室状況 | 日付範囲ごとの現在の価格と実際に予約可能な状況 | キャッシュされた料金は確認時に失敗し、信頼を損なう |
| 予約作成 | ホテルが受け取る実際の予約を作成する | これがなければ紹介リンクであって製品ではない |
| 支払い | 予約の一部として料金を受け取る | 他サイトへの引き渡しはコンバージョンが死ぬポイント |
| 確認とウェブフック | ゲスト、ホテル、システムに何が起きたかを伝える | そうしないとサポート負荷や照合のギャップが生じる |
開発者が見つける多くの「ホテルAPI」は最初の機能、時には2つ目までをカバーします。取引は難しい部分であり、製品かどうかを決める部分です。
どの供給元を統合するのか？
Section titled “どの供給元を統合するのか？”この質問は以降のすべてを決定します。チェーンを通じて再販される供給は、料金にマークアップが含まれ、空室状況は古く、予約に関するホテルへの問い合わせルートがありません。ホテルから直接来る供給は、ホテル自身の料金、リアルタイムの空室状況、そして予約が存在することを知っているホテルを伴います。
旅行者がホテル自身のウェブサイトと比較するような場合（ほとんどの場合）、ホテル管理の供給は価格が悪いという気まずい瞬間を避けられます。
マーチャント・オブ・レコードは誰か
Section titled “マーチャント・オブ・レコードは誰か”ホテル予約を自分で構築する場合、マーチャント・オブ・レコードになることは、支払い責任、チャージバック、返金、税務処理、そして多くの場合は各市場での旅行代理店ライセンスを負うことを意味します。
Winkではホテルがマーチャント・オブ・レコードのままで支払いはホテルのために回収されるため、統合者はその負担を負いません。マーチャント・オブ・レコードの取り決めは、パートナーが実際に支払いを受け取る必要があるAPI統合で利用可能で、その場合は独自のライセンス要件があります。
3つの統合レベル
Section titled “3つの統合レベル”- ウェブコンポーネント。 既存ページに予約可能な検索、部屋リスト、チェックアウトを埋め込む。バックエンド作業不要で、レイアウトの制御は最小。
- REST API。 OAuth2認証で検索、料金、予約作成、確認を完全に制御。予約フローが製品の体験の一部である場合に使用。
- MCPサーバー。 AIエージェント向けに同じ機能を公開し、アシスタントがユーザーをウェブサイトに渡す代わりに検索、価格設定、予約を完了できる。
これら3つは排他的ではなく、製品はマーケティング用にコンポーネントを使い、コアフローにAPIを使うことが一般的です。
最初に作るべきもの
Section titled “最初に作るべきもの”- 1都市・1日付範囲の検索と価格。 何か設計する前に実際の料金を流す。
- 1件のテスト予約を支払いと確認まで一通り作成。
- UIを作る前に
booking.createとキャンセルイベントを購読。 - アトリビューションモデルを早めに決定。 ソースコンテキストは予約に引き継がれないと後でレポートが推測になる。
- 失敗ケースを処理。 見積もりと予約の間に空室がなくなる、支払い拒否、部分返金など。
開発者が知るべき料金体系
Section titled “開発者が知るべき料金体系”ConsumerとBooking Engine APIは無料です。Partner APIは月10,000泊の無料枠があり、その後は単位ごとに課金されます。確定予約にはホテルの1.5%のプラットフォーム手数料とカード処理コストがかかり、10%のデフォルトコミッションはあなたの製品が予約を促した場合に適用されます — これが統合者が支払うのではなく稼ぐ仕組みです。
よくある間違い
Section titled “よくある間違い”- キャッシュされた料金で構築すること。 開発時は問題なく見えても本番で失敗する。
- 支払いをリダイレクトに任せること。 どの引き渡しも予約を失う。
- ローンチまでウェブフックを無視すること。 照合が手作業になる。
- 必要なくマーチャント・オブ・レコードになること。 それは技術的な問題ではなく、ライセンスと責任の問題。
- ソースコンテキストを渡さないこと。 アトリビューションは後から再構築できない。