[ overview ]
This article explains the development procedure for developing an in-house system that retrieves reservation information from the AirHost API and provides functions that are not provided by AirHost PMS, such as accounting and cleaning management.
Basically, reservation information is read-only. It is not an API for creating a check-in app. If you would like to use advance check-in or self-check-in, please use the check-in option provided by AirHost.
Note 1 : You can retrieve all reservation information including OTA reservations using AirHost API. However, you can only update reservation information created from your system via API.
Note 2: If you are planning to send messages to guests, please understand that this is difficult to achieve. The reason is that for OTAs such as Airbnb, Booking.com, and Rakuten Travel, where messages can only be sent and received via API, email address information is not included in the reservation information.
Note 3 : It is possible to obtain reservation information, but it is not possible to obtain guest information obtained during advance check-in or message exchanges with guests.
[Details]
Implementation image
Please make sure to design your system so that a copy of the facility and reservation data obtained from the AirHost API is kept in your internal database. You cannot implement a system that retrieves real-time data via API each time.
Processing Steps
Initial data acquisition
Call GET /properties to get information for all properties and keep a copy in the local DB.
Call GET /stays to get the reservation data and keep a copy in the local DB.
Keeping data up to date
To keep the facility and reservation information stored in the local DB up to date, call GET /feeds at intervals such as every 5 minutes to check the "event" information and update it in the local DB as necessary.
Full Scan
You can ensure data consistency by retrieving all future bookings with GET /stays about once a day.
Displaying information on an internal system page
Please use the data in the local DB to display information on your company's internal system. If you design it to call the AirHost API every time, it will not work due to access restrictions.
Creating reservation data
You can also create reservations from your internal system via the API by calling POST /stays.
Reservations created via POST /stays can also be updated via PUT /room_reservations/{id}. *Other reservations, such as OTA reservations, cannot be updated.
API Documentation and Available Endpoints
API documentation: https://airhost.stoplight.io/docs/airhost-public-api-doc/branches/japanese/b8pf0iy7p7mrw-
*The only APIs available in the "API for internal systems" package are listed below.
GET /properties
POST /stays
GET /feeds (all events available except availabilities.update)
POST /commit_feeds
GET /stays (gets all reservations, including OTA reservations)
POST /stays
PUT /room_reservations/{id} (only for reservations created with POST /stays)
About the RoomReservation API Guest Count Fields(2026.05.11)
The guest count fields in the RoomReservation API are mapped based on each OTA’s own guest classification and definitions.
AirHost aggregates reservation data from multiple OTAs, but each OTA defines “child,” “infant,” and child sub-categories (ChildA–D) differently.
Therefore, the API does not provide a unified semantic definition, but instead returns the result of the OTA-specific mapping as accurately as possible.
As a result, the same field may have different meanings depending on the source OTA of the reservation.
Basic Meaning of Each Field
Standard Guest Count Fields
adult_count
Number of adultschild_count
Number of children (excluding infants)infant_count
Number of infants
ChildA – ChildD Fields
child_a_count through child_d_count are a more detailed breakdown of child_count based on the Japanese hotel / ryokan industry age-tier convention.
child_a_count
Roughly upper elementary school age (~10–12 years old, ~70% meal, adult-size bedding)child_b_count
Roughly lower elementary school age (~6–9 years old, ~50% meal, adult-size bedding)child_c_count
Preschool child with meal and futonchild_d_count
Preschool child with meal only and no futon
Relationship Between child_d_count and Co-Sleeping
On some OTAs (Rakuten Travel, Ikyu, and Temairazu), child_d_count is used with the meaning of “no bedding required.”
Therefore, it is roughly treated as equivalent to “co-sleeping.”
However, because the definition differs by OTA, child_d_count cannot be considered a completely reliable indicator of co-sleeping guests.
Reasons
Numeric-age OTAs such as Booking.com / Expedia / Opera never generate
child_d_countThe “no meal, no bedding (ChildF)” category in Rakuten Travel / Ikyu is dropped during normalization
On Temairazu, the same count may be written into both
infant_countandchild_d_countOn Rakuten Travel / Ikyu,
infant_countitself may include infant categories that require bedding
For these reasons, neither infant_count nor child_d_count should be interpreted directly as “co-sleeping guest count.”
Among currently supported OTAs, Airbnb’s infant_count is the most reliable field for bedding planning purposes because it has relatively clear “Under 2 years old” semantics.
Relationship Between child_count and ChildA–D
Important Note
The following relationship does not guarantee strict equality:
child_a + child_b + child_c + child_d ≤ child_count
In practice, both < and > cases can occur.
This is because ChildA–D is not a strict partition of child_count, but rather a best-effort categorization based on OTA-provided data.
Cases Where the A–D Total Is Less Than child_count (<)
For numeric-age OTAs (Booking.com / Expedia / Opera, etc.), AirHost performs the following approximate mapping:
Ages 6–12 → ChildA
Ages 3–6 → ChildB
However, ages under 3 or over 12 are excluded from ChildA–D.
Example
One 5-year-old guest
One 13-year-old guest
Result:
child_count = 2child_a + child_b + child_c + child_d = 1
This happens because the 13-year-old falls outside the ChildA–D mapping range and is excluded.
Cases Where the A–D Total Is Greater Than child_count (>)
On Japanese OTAs (Ikyu, Rakuten Travel, Temairazu), infant categories that are excluded from the OTA’s own child_count may still appear in the ChildA–D breakdown.
Example (Ikyu)
On Ikyu:
child_count = ChildA + ChildB
However, child_a/b/c/d_count also includes ChildC and ChildD.
As a result:
child_a + child_b + child_c + child_d > child_count
can occur.
Important Notes
Treat
child_countas “the OTA’s own definition of children”Treat
child_a/b/c/d_countas a best-effort conversion into Japanese hotel industry-style child categoriesDo not assume that these values will always match or sum consistently