[ 概要 ]
AirHost API から予約情報を取得して、会計処理や清掃管理など、AirHost PMS が提供しない機能を社内システムとして開発したい場合の開発手順を説明します。
基本的に予約情報は読み取り専用です。チェックインアプリを作成するための API ではありません。 事前チェックインやセルフチェックイン機能をご希望の場合には、AirHost が提供するチェックインオプションをご利用下さい。
注意１：AirHost API を利用して、OTA 予約を含む全ての予約情報を取得することが可能ですが、予約情報の更新に関しては API 経由で御社システムから作成した予約に限られます。
注意２：ゲストへのメッセージ送信を計画している場合、実現は難しいことをご理解下さい。 理由としては、Airbnb や Booking.com、楽天トラベルなど API 経由でないとメッセージ送受信が出来ない OTA に関しては、予約情報にメールアドレスの情報が含まれないためです。
注意３：予約情報の取得は可能ですが、事前チェックインで取得した宿泊者情報やゲストとのメッセージのやり取りの情報などは取得できません。
[ 詳細 ]
実装イメージ
AirHost API から取得した施設・予約データは、必ず社内システムのデータベース内にコピーを保持するように設計して下さい。 都度 API 経由でリアルタイムデータを取得するような実装は出来ません。
処理手順
初期データ取得
GET /properties をコールして、全施設の情報を取得して、ローカル DB 内にコピーを保持します。
GET / List room types and rates under a given property をコールして、必要に応じてルームタイプや料金プランに関する情報を取得して、ローカル DB 内にコピーを保持します。
GET /stays をコールして、予約データを取得して、ローカル DB 内にコピーを保持します。
最新データの維持
ローカル DB 内に保持した施設・予約情報を最新の状態に保つためには、GET /feeds を5分毎などの間隔でコールして、"event" 情報を確認、必要に応じてローカル DB に反映します。
フルスキャン
1日一回程度、GET /stays で全ての未来予約を取得することでデータの一貫性を保証頂くことが出来ます。
社内システムページへの情報の表示
社内システムへの情報表示は、すべてローカル DB 内にあるデータを利用して処理を行うようにして下さい。 都度 AirHost API をコールするような設計にすると、アクセス制限で動作しなくなります。
予約データの作成
POST /stays をコールすることで、社内システム側から API 経由で予約データを作成することも出来ます。
POST /stays 経由で作成した予約情報に関しては、PUT /room_reservations/{id} から更新することも可能です。 ※ OTA 予約など他の予約は更新出来ません。
API ドキュメントと利用可能なエンドポイント
API ドキュメント：https://airhost.stoplight.io/docs/airhost-public-api-doc/branches/japanese/b8pf0iy7p7mrw-
※「社内システム用 API」パッケージで利用可能な API は、以下のみになります。
Feed (availabilities.update 以外のイベントが利用可能) |
|
Pull Latest Updates | GET |
Commit Feeds Cursor | POST |
Push webhook notification | POST |
Property |
|
List Properties | GET |
Retrieve a Property | GET |
Product |
|
List room types and rates under a given property | GET |
Room Reservation |
|
Update a Room Reservation（API で作成した予約のみ対象に、宿泊人数、チェックイン/アウト日、請求金額などを更新可能） | PUT |
Stay |
|
List Stays（OTA 予約を含む全予約を取得可能） | GET |
Create a Stay | POST |
Retrieve a Stay | GET |
予約者名と宿泊者名の取得について
AirHost API では、予約者情報と宿泊者情報は別オブジェクトとして返却されます。用途に応じて取得先が異なりますのでご注意ください。
■ 取得対象の違い
予約者名（Stay.booker）
→ GET /stays で取得可能（予約を行った方の情報）
宿泊者名（RoomReservation.main_guest）
→ GET /room_reservations/{id} で取得可能（実際に宿泊される代表者の情報）
■ 注意事項
予約者（booker）と宿泊者（main_guest）は常に同一とは限りません。
RoomReservation の人数関連フィールドについて(2026.05.11)
RoomReservation の人数関連フィールドは、OTAごとに異なるゲスト区分・定義をもとにマッピングされています。
AirHostでは複数のOTAから予約情報を取得していますが、各OTAで「child」「infant」および子ども区分（ChildA～D）の定義が異なります。
そのため、APIでは統一された意味を返しているのではなく、OTAごとの定義を可能な限り反映した結果を返しています。
つまり、同じフィールド名であっても、予約元OTAによって意味や解釈が異なる場合があります。
各フィールドの基本的な意味
標準人数フィールド |
|
ChildA ～ ChildD フィールド
|
|
child_d_count と添い寝の関係について
一部OTA（楽天トラベル、一休、手間いらず）では、child_d_count は「寝具不要」の意味として利用されています。そのため、概ね「添い寝」に近い意味として扱われています。ただし、OTAごとに定義が異なるため、child_d_count を「添い寝人数」として完全に信頼することはできません。
理由
Booking.com / Expedia / Opera のような「年齢ベースOTA」では
child_d_countは生成されない楽天トラベル・一休の「食事なし・布団なし（ChildF）」カテゴリは正規化時に削除される
手間いらずでは同じ人数が
infant_countとchild_d_countの両方に重複して書き込まれる場合がある楽天トラベル・一休では
infant_countにも「寝具あり」の幼児区分が含まれる場合がある
そのため、infant_count や child_d_count を単純に「添い寝人数」とみなすことはできません。
なお、Airbnb の infant_count は「2歳未満」という比較的明確な定義のため、寝具不要人数の参考値としては最も信頼性が高いフィールドです。
child_count と ChildA～D の関係について
注意点
以下の関係は、厳密な一致を保証するものではありません。
child_a + child_b + child_c + child_d ≤ child_count
さらに、実際には < だけでなく > になるケースもあります。これは、ChildA～D が child_count を完全に分割した値ではなく、「OTA情報をもとに可能な範囲で分類した結果」だからです。
A～D 合計が child_count より少なくなるケース（<）
年齢ベースOTA（Booking.com / Expedia / Opera など）では、AirHost側で以下のような簡易マッピングを行っています。
6～12歳 → ChildA
3～6歳 → ChildB
ただし、3歳未満や12歳超は ChildA～D に含まれません。
例
5歳 × 1名
13歳 × 1名
の場合：
child_count = 2child_a + child_b + child_c + child_d = 1
となります。13歳は ChildA～D の範囲外のため除外されるためです。
A～D 合計が child_count より多くなるケース（>）
日本OTA（一休・楽天トラベル・手間いらず）では、OTA側の child_count に含まれない「幼児区分」が ChildA～D 側には含まれる場合があります。
例（一休）
一休では：child_count = ChildA + ChildB
という扱いですが、child_a/b/c/d_count 側には ChildC・ChildD も含まれます。
そのため：child_a + child_b + child_c + child_d > child_count となる場合があります。
注意点
child_countは「OTA側独自定義の child 数」として扱ってくださいchild_a/b/c/d_countは、日本の宿泊業界で一般的に使用される子ども区分に基づき、可能な範囲で分類・変換された値です。両者が一致することを前提に実装・運用しないでください