ガイド

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. 1

    エンドポイントとメソッド

    操作のアドレスと、それに対して使う動詞。availabilityへのPOSTは「客室を検索する」という意味です。

  2. 2

    認証

    キー、トークン、署名で呼び出し元を証明します。サプライヤーはサンドボックス用と本番用に別々の認証情報を発行します。

  3. 3

    ペイロード

    構造化された入力:都市、日付、人数、通貨。各フィールドはサプライヤーのドキュメントで定義されます。

  4. 4

    ステータスコード

    呼び出しの結果を示す数字:200は成功、4xxはリクエスト側の問題、5xxはサプライヤー側の問題です。

  5. 5

    リクエストID

    双方が保持する識別子。サポートが「この予約はどうなったか」と尋ねるとき、検索するのはこれです。

  6. 6

    レスポンス本文

    サプライヤーの形式で返る回答で、あなたのプラットフォームが自身の客室、料金、ポリシーにマッピングします。

1件の予約、4つのシステム

ホテル予約の間にAPI連携が行うこと

2泊の滞在を検索からバウチャーまで追ってみましょう。矢印はすべてAPI呼び出しで、旅行者が目にするのは最初と最後だけです。

  1. 01旅行者予約プラットフォームドバイのホテルを検索、2泊、2名
  2. 02予約プラットフォームサプライヤーAPI日付、人数、通貨を含む空室リクエスト
  3. 03サプライヤーAPI予約プラットフォーム客室、料金、ポリシー、レートキー
  4. 04予約プラットフォーム旅行者あなたのマークアップと通貨を適用して結果を表示
  5. 05予約プラットフォームサプライヤーAPI決済前に選択したレートキーの価格を再確認
  6. 06予約プラットフォーム決済ゲートウェイ合計金額の決済オーソリ
  7. 07決済ゲートウェイ予約プラットフォームオーソリ完了、署名付きwebhookを受信
  8. 08予約プラットフォームサプライヤーAPI宿泊者情報を含む予約リクエスト
  9. 09サプライヤーAPI予約プラットフォーム確認番号とキャンセル条件
  10. 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連携

すでに存在するインターフェースにあなたの製品を接続します。APIはサプライヤーのもので、あなたはクライアント、マッピング、周辺のルールを構築します。

API開発

他のシステムがあなたの製品に接続するためのインターフェースを作ります。たとえば代理店のツールが呼び出せるB2B APIです。契約とそのバージョンはあなたのものです。

多くの旅行プロジェクトは両方を必要とします。プラットフォームは一方でサプライヤーを連携し、もう一方で代理店やパートナー向けに独自のAPIを公開します。

導入前と導入後

システムが連携されると何が変わるか

同じ予約の5つのステップを、サプライヤーのポータルで手作業で行う場合と、API連携で行う場合で比べます。

検索

連携なし手作業

担当者が各サプライヤーのポータルを開き、価格を見積もりに書き写す。

API連携あり自動

1回の検索が接続済みの全サプライヤーに広がり、1つのリストが返る。

価格

連携なし手作業

マークアップは表計算で追加し、見積もりを送る頃には料金が変わっていることも。

API連携あり自動

マークアップ、税、通貨ルールはレスポンス時に適用され、決済前に料金を再確認する。

予約

連携なし手作業

宿泊者情報をサプライヤーのポータルに再入力し、誤字が予約ミスになる。

API連携あり自動

情報は一度だけ送られ、検証され、サプライヤーの確認とともに保存される。

決済

連携なし手作業

決済は別途回収し、後から予約と突き合わせる。

API連携あり自動

オーソリ、売上確定、返金が予約参照番号に紐づく。

アフター対応

連携なし手作業

キャンセルや変更のたびに再ログインとメールが必要。

API連携あり自動

変更とキャンセルは同じ接続を通り、記録を更新する。

用語

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: 予約、決済、サプライヤーの参照番号が照合される

全ケース合格、認定の準備完了

スコープ確定に必要なもの

  1. 1サプライヤー契約、ドキュメント、サンドボックスの認証情報
  2. 2市場、通貨、商品、ユーザー権限
  3. 3検索、予約、変更、キャンセル、返金の範囲
  4. 4認定要件と本番アクセスの手順

サプライヤー接続の準備はできています

PHPTRAVELSは、サプライヤー、ゲートウェイ、業務ツールをソースコード付きで納品されるセルフホスト型プラットフォームに統合します。買い切り3プランは料金をご覧いただくか、特定のAPIについてお問い合わせください。

よくある質問

API連携に関する質問と回答

初めての連携プロジェクトの前に寄せられる質問への短い回答です。

営業に相談

API連携とは、2つのソフトウェアシステムが自動的にデータを交換し、処理を起動できるようにする接続です。一方が構造化されたリクエストを送り、もう一方が構造化されたレスポンスを返し、双方が合意したセキュリティとデータのルールに従います。

旅行業界では、予約プラットフォームを航空、ホテル、ツアー、レンタカーのサプライヤー、決済ゲートウェイ、業務ツールとつなぐことです。再入力なしで検索、価格確認、予約、キャンセル、返金、照合を支えます。

RESTはアーキテクチャスタイルで、通常はHTTP上でJSONをやり取りします。XMLはデータ形式で、GDSやベッドバンクのサプライヤーでは今も一般的で、SOAPに包まれることが多いです。どちらを使うかはサプライヤーの契約とドキュメントが決めます。

サプライヤーへのアクセス、対象のエンドポイント、認定、マッピングルール、予約の特殊ケースによります。信頼できる見積もりは、ドキュメント、認証情報、必要なワークフローを確認した後に出せます。

認証、正常および不正なリクエスト、タイムアウト、レート制限、価格変更、重複送信、キャンセル、返金、照合をテストします。本番では、すべてのリクエストが予約参照番号までたどれる必要があります。

いいえ。連携は既存のAPIにあなたの製品を接続すること、開発は他者が接続するインターフェースを作ることです。旅行プラットフォームは両方を必要とすることが多く、一方でサプライヤーを連携し、もう一方でパートナー向けにB2B APIを公開します。