ガイド
API連携とは、旅行事業者向けにわかりやすく
API連携とは、2つのソフトウェアシステムが人の再入力なしにデータを交換し、処理を起動できるようにする接続のことです。このガイドでは、旅行者・予約プラットフォーム・サプライヤーAPI・決済ゲートウェイの間を流れる1件のホテル予約を例に、その仕組みを解説します。
- 1つのリクエスト、1つのレスポンス
- REST、XML、SOAP、webhook
- 4つのシステムをたどる1件の予約
- 連携のテスト方法
定義
API連携とは何か、やさしい言葉で
APIはアプリケーション・プログラミング・インターフェースの略で、他のソフトウェアが対話できるようにシステムが公開する一連のルールです。API連携とは、データが自動的に流れ、処理が自動的に起こるように、あなたのプラットフォームをそのインターフェースのひとつに接続する作業です。
旅行業界では、そのプラットフォームは通常旅行予約ソフトウェアのような予約システムで、インターフェースはサプライヤー、決済ゲートウェイ、業務ツールのものです。旅行API連携のページではPHPTRAVELSがこうした接続をどう提供するかを説明し、すべての連携には接続済みのサプライヤーを掲載しています。
データを交換する
料金、空室、顧客情報、ステータス更新が構造化された形式でシステム間を行き来します。
処理を自動化する
検索、予約、決済、キャンセル、照合はリクエストとして行われ、誰かが手作業で繰り返す手順ではなくなります。
結果を追跡する
すべての呼び出しに参照番号が付くため、失敗した予約を原因となったリクエストまでたどれます。
リクエスト
POST /v1/hotels/availability HTTP/1.1Host: api.supplier.exampleAuthorization: Bearer sk_test_••••••••Content-Type: application/json{ "city": "DXB", "check_in": "2026-11-12", "check_out": "2026-11-14", "guests": 2, "currency": "USD"}レスポンス
HTTP/1.1 200 OKContent-Type: application/jsonX-Request-Id: req_7f3a91{ "hotel": "Palm Marina Hotel", "room": "Deluxe, 2 adults", "rate": { "amount": 438.00, "currency": "USD" }, "refundable": true, "rate_key": "rk_19d2c7"}1回のAPI呼び出しの構造
- 1
エンドポイントとメソッド
操作のアドレスと、それに対して使う動詞。availabilityへのPOSTは「客室を検索する」という意味です。
- 2
認証
キー、トークン、署名で呼び出し元を証明します。サプライヤーはサンドボックス用と本番用に別々の認証情報を発行します。
- 3
ペイロード
構造化された入力:都市、日付、人数、通貨。各フィールドはサプライヤーのドキュメントで定義されます。
- 4
ステータスコード
呼び出しの結果を示す数字:200は成功、4xxはリクエスト側の問題、5xxはサプライヤー側の問題です。
- 5
リクエストID
双方が保持する識別子。サポートが「この予約はどうなったか」と尋ねるとき、検索するのはこれです。
- 6
レスポンス本文
サプライヤーの形式で返る回答で、あなたのプラットフォームが自身の客室、料金、ポリシーにマッピングします。
1件の予約、4つのシステム
ホテル予約の間にAPI連携が行うこと
2泊の滞在を検索からバウチャーまで追ってみましょう。矢印はすべてAPI呼び出しで、旅行者が目にするのは最初と最後だけです。
- 01ドバイのホテルを検索、2泊、2名送信元: 旅行者, 送信先: 予約プラットフォーム
- 02日付、人数、通貨を含む空室リクエスト送信元: 予約プラットフォーム, 送信先: サプライヤーAPI
- 03客室、料金、ポリシー、レートキー送信元: サプライヤーAPI, 送信先: 予約プラットフォーム
- 04あなたのマークアップと通貨を適用して結果を表示送信元: 予約プラットフォーム, 送信先: 旅行者
- 05決済前に選択したレートキーの価格を再確認送信元: 予約プラットフォーム, 送信先: サプライヤーAPI
- 06合計金額の決済オーソリ送信元: 予約プラットフォーム, 送信先: 決済ゲートウェイ
- 07オーソリ完了、署名付きwebhookを受信送信元: 決済ゲートウェイ, 送信先: 予約プラットフォーム
- 08宿泊者情報を含む予約リクエスト送信元: 予約プラットフォーム, 送信先: サプライヤーAPI
- 09確認番号とキャンセル条件送信元: サプライヤーAPI, 送信先: 予約プラットフォーム
- 10バウチャー、請求書、予約参照番号送信元: 予約プラットフォーム, 送信先: 旅行者
- 01旅行者予約プラットフォームドバイのホテルを検索、2泊、2名
- 02予約プラットフォームサプライヤーAPI日付、人数、通貨を含む空室リクエスト
- 03サプライヤーAPI予約プラットフォーム客室、料金、ポリシー、レートキー
- 04予約プラットフォーム旅行者あなたのマークアップと通貨を適用して結果を表示
- 05予約プラットフォームサプライヤーAPI決済前に選択したレートキーの価格を再確認
- 06予約プラットフォーム決済ゲートウェイ合計金額の決済オーソリ
- 07決済ゲートウェイ予約プラットフォームオーソリ完了、署名付きwebhookを受信
- 08予約プラットフォームサプライヤーAPI宿泊者情報を含む予約リクエスト
- 09サプライヤーAPI予約プラットフォーム確認番号とキャンセル条件
- 10予約プラットフォーム旅行者バウチャー、請求書、予約参照番号
中央のプラットフォームこそがAPI連携の居場所です。旅行者の画面と各サプライヤーの形式を相互に変換し、すべての参照番号を保存します。
同じ流れがGDSと連携する航空券予約ソフトウェア、アクティビティサプライヤーと連携するツアーオペレーター向けソフト、任意のゲートウェイと連携する決済ゲートウェイ連携にも当てはまり、変わるのはフィールド名だけです。
連携のスタイル
REST、XML、SOAP、webhook、GraphQL
サプライヤーはさまざまなスタイルでインターフェースを公開します。どのスタイルかは好みではなくサプライヤーのドキュメントが決めるため、旅行プラットフォームはすべてに対応する必要があります。
RESTとJSON
JSON- データ形式
- JSONドキュメント
- 転送方式
- HTTPメソッド:GET、POST、PUT、DELETE
- 旅行業界での用途
- 新しい航空、ホテル、アクティビティ、決済のAPI
- 強み
- コンパクトなペイロードと豊富な開発ツール
- 注意点
- 仕様がゆるく、サプライヤーごとにRESTの解釈が異なる
XMLとSOAP
XML- データ形式
- XMLドキュメント、多くは厳密なスキーマ付き
- 転送方式
- SOAPエンベロープまたは素のXMLによるHTTP POST
- 旅行業界での用途
- GDS、ベッドバンク、確立されたホテル・ツアーシステム
- 強み
- 正式な契約、署名、サービス定義
- 注意点
- 冗長なメッセージと重いパース処理
Webhook
EVENT- データ形式
- 相手側からプッシュされるJSONまたはXML
- 転送方式
- 登録したURLへのHTTP POST
- 旅行業界での用途
- 決済結果、予約ステータス変更、発券更新
- 強み
- ポーリング不要で、何かが起きたときに通知される
- 注意点
- 署名の検証と重複の処理が必須
GraphQL
QUERY- データ形式
- 送信したクエリの形に整形されたJSON
- 転送方式
- 単一のHTTPエンドポイント
- 旅行業界での用途
- 一部の新しい流通プラットフォームや社内API
- 強み
- 必要なフィールドだけを正確に要求できる
- 注意点
- 旅行サプライヤーの対応はまだ少ない
API連携とAPI開発の違い
すでに存在するインターフェースにあなたの製品を接続します。APIはサプライヤーのもので、あなたはクライアント、マッピング、周辺のルールを構築します。
他のシステムがあなたの製品に接続するためのインターフェースを作ります。たとえば代理店のツールが呼び出せるB2B APIです。契約とそのバージョンはあなたのものです。
多くの旅行プロジェクトは両方を必要とします。プラットフォームは一方でサプライヤーを連携し、もう一方で代理店やパートナー向けに独自のAPIを公開します。
導入前と導入後
システムが連携されると何が変わるか
同じ予約の5つのステップを、サプライヤーのポータルで手作業で行う場合と、API連携で行う場合で比べます。
検索
担当者が各サプライヤーのポータルを開き、価格を見積もりに書き写す。
1回の検索が接続済みの全サプライヤーに広がり、1つのリストが返る。
価格
マークアップは表計算で追加し、見積もりを送る頃には料金が変わっていることも。
マークアップ、税、通貨ルールはレスポンス時に適用され、決済前に料金を再確認する。
予約
宿泊者情報をサプライヤーのポータルに再入力し、誤字が予約ミスになる。
情報は一度だけ送られ、検証され、サプライヤーの確認とともに保存される。
決済
決済は別途回収し、後から予約と突き合わせる。
オーソリ、売上確定、返金が予約参照番号に紐づく。
アフター対応
キャンセルや変更のたびに再ログインとメールが必要。
変更とキャンセルは同じ接続を通り、記録を更新する。
用語
APIドキュメントで出会う用語
ほぼすべてのサプライヤーの開発者ポータルに登場する12の言葉を、旅行業界での使われ方で定義します。
API
アプリケーション・プログラミング・インターフェース。システムと対話するための公開されたルール。
認証
APIキー、bearerトークン、署名、承認済みIPアドレスで呼び出し元を証明すること。
認定
本番用の認証情報を発行する前にサプライヤーが行う、あなたの連携の審査。
エンドポイント
検索、予約、キャンセルなど、1つの操作に対する1つのアドレス。
冪等性
同じリクエストを2回送っても結果は1つになり、二重予約と二重請求を防ぐ。
マッピング
サプライヤーのフィールド、コード、名称をあなたのプラットフォーム独自のデータモデルに変換すること。
ペイロード
リクエストまたはレスポンスの中で運ばれるデータで、通常はJSONかXML。
レート制限
サプライヤーが拒否を始める前に、1秒または1日あたりに許可する呼び出し回数。
リクエストとレスポンス
1回の呼び出し。あなたのプラットフォームが尋ね、サプライヤーが答え、双方が記録する。
サンドボックス
架空の在庫とテストカードを備えたテスト環境で、実際には何も予約も請求もされない。
ステータスコード
結果を要約するHTTPの数字:200 成功、401 未認証、429 レート制限、500 サプライヤーエラー。
Webhook
逆方向の呼び出し。イベントが起きたときにサプライヤーやゲートウェイがあなたのプラットフォームに通知する。
テストとスコープ
旅行向けAPI連携を本番稼働前にテストする方法
連携は、異常系が正しく振る舞って初めて完成です。認定と本番用認証情報への切り替えの前に、サプライヤーのサンドボックスで以下のケースをテストします。
run integration tests
サプライヤーサンドボックス、9ケース
- OK: 有効および期限切れの認証情報での認証
- OK: 不正なリクエストを読みやすいエラーで拒否
- OK: サプライヤーのタイムアウトを予約を宙に浮かせずに処理
- OK: レート制限を守り、待機後に再試行
- OK: 再確認で価格変更を検知し、決済前に表示
- OK: 重複送信は2件目ではなく最初の予約を返す
- OK: キャンセルを適用し、手数料を計算
- OK: 元の決済に対して返金を実行
- OK: 予約、決済、サプライヤーの参照番号が照合される
全ケース合格、認定の準備完了
API連携とは、2つのソフトウェアシステムが自動的にデータを交換し、処理を起動できるようにする接続です。一方が構造化されたリクエストを送り、もう一方が構造化されたレスポンスを返し、双方が合意したセキュリティとデータのルールに従います。
旅行業界では、予約プラットフォームを航空、ホテル、ツアー、レンタカーのサプライヤー、決済ゲートウェイ、業務ツールとつなぐことです。再入力なしで検索、価格確認、予約、キャンセル、返金、照合を支えます。
RESTはアーキテクチャスタイルで、通常はHTTP上でJSONをやり取りします。XMLはデータ形式で、GDSやベッドバンクのサプライヤーでは今も一般的で、SOAPに包まれることが多いです。どちらを使うかはサプライヤーの契約とドキュメントが決めます。
サプライヤーへのアクセス、対象のエンドポイント、認定、マッピングルール、予約の特殊ケースによります。信頼できる見積もりは、ドキュメント、認証情報、必要なワークフローを確認した後に出せます。
認証、正常および不正なリクエスト、タイムアウト、レート制限、価格変更、重複送信、キャンセル、返金、照合をテストします。本番では、すべてのリクエストが予約参照番号までたどれる必要があります。
いいえ。連携は既存のAPIにあなたの製品を接続すること、開発は他者が接続するインターフェースを作ることです。旅行プラットフォームは両方を必要とすることが多く、一方でサプライヤーを連携し、もう一方でパートナー向けにB2B APIを公開します。
