[AirHost API] Implementing the "Internal System" Integration FAQ

Retrieving the Booker Name and Guest Name

In the AirHost API, booker information and guest information are returned as separate objects.

Please note that the source of the information differs depending on your use case.

■ Differences in what information is retrieved:
Reservation name (Stay.booker)
→ Can be retrieved with GET /stays (information of the person who made the reservation)

Guest name (RoomReservation.main_guest)
→ Can be obtained via GET /room_reservations/{id} (Information of the representative who will actually be staying)

■ Important Note:
The person who made the reservation (booker) and the guest (main_guest) are not always the same person.

About the Guest Count Fields in RoomReservation (2026-05-11)

The guest count fields in RoomReservation are mapped based on the guest categories and definitions used by each OTA.

AirHost imports reservation data from multiple OTAs, but each OTA defines child, infant, and child categories (ChildA–ChildD) differently.

As a result, the API does not return standardized definitions for these fields. Instead, it returns values that reflect each OTA's definitions as closely as possible.

Therefore, even when the field names are the same, their meaning and interpretation may differ depending on the source OTA.

Basic Meaning of Each Field

Category	Description
Standard Guest Count Fields	`adult_count`　Number of adults `child_count`　Number of children (excluding infants) `infant_count`　Number of infants and toddlers
ChildA–ChildD Fields `child_a_count`~ is a value derived `child_d_count`from the age categories used in the Japanese hotel and inn industry .`child_count`	`child_a_count`　Equivalent to upper elementary school age (approximately 10-12 years old, approximately 70% of meals, adult bedding) `child_b_count`　Equivalent to lower elementary school age (approximately 6-9 years old, meals approximately 50%, adult bedding) `child_c_count`　Preschool children (meals and bedding provided) `child_d_count`　Preschool children (meals provided, bedding not included)

Important Specifications and Integration Considerations for Handling Co-Sleeping Children and Guest Counts

Topic	Description	Reason
Relationship Between `child_d_count` and Co-Sleeping Children	For some OTAs (such as Rakuten Travel, Ikkyu, and Temairazu), `child_d_count` is used to indicate guests who do not require bedding. As such, it is generally treated as being similar to co-sleeping children. However, because each OTA defines this category differently, `child_d_count` should not be considered a completely reliable indicator of the number of co-sleeping children.	- Age-based OTAs such as Booking.com, Expedia, and Opera do not generate `child_d_count`. - In Rakuten Travel and Ikkyu, the "No Meals / No Bedding (Child F)" category is removed during data normalization. - In Temairazu, the same guest count may be duplicated in both `infant_count` and `child_d_count`. - In Rakuten Travel and Ikkyu, `infant_count` may also include infant categories with bedding provided. Therefore, `infant_count` and `child_d_count` should not be interpreted directly as the number of co-sleeping children. For Airbnb, `infant_count` has a relatively clear definition (children under 2 years old), making it the most reliable field for estimating guests who do not require bedding.
Regarding the relationship between child_count and ChildA-D	[Notes] The following relationships do not guarantee a strict correspondence. `child_a + child_b + child_c + child_d ≤ child_count` Furthermore, there are cases where it's `<`not just that . This is because ChildA to D are not values that completely divide the categories, but rather "the result of classifying them to the extent possible based on OTA information."`>child_count`	Cases where the sum of A-D is less than child_count (<) Age-based OTAs (such as Booking.com, Expedia, and Opera) perform the following simplified mapping on the AirHost side: 6-12 years old → Child A 3-6 years old → Child B However, children under 3 years old and over 12 years old are not included in Child A-D. [example] 5 years old x 1 person 13 years old x 1 person in the case of: `child_count = 2` `child_a + child_b + child_c + child_d = 1` This is because 13-year-olds are excluded as they fall outside the range of Child A to D.
Cases where the sum of A-D is greater than child_count (>)	Japanese online travel agencies (OTAs) such as Ikkyu, Rakuten Travel, and Temairazu `child_count`may include "infant categories" (Child A-D) that are not included in the OTA's own categories.	[Example (Ikkyu)] At Ikkyu:`child_count = ChildA + ChildB` This is how it's treated, but `child_a/b/c/d_count`ChildC and ChildD are also included in that category. Therefore, `child_a + child_b + child_c + child_d > child_count`　this may occur. [Notes] `child_count`Please treat this as "the number of children defined by the OTA itself." `child_a/b/c/d_count`These values are classified and converted to the extent possible based on the child classifications commonly used in the Japanese lodging industry. Do not implement or operate the system assuming that both parties are the same.

Cleaning Management

Scenario	Description
Using the API for Cleaning Management	AirHost can provide the reservation-related data required by your cleaning management system. However, AirHost does not include cleaning management functionality itself. For example, the API cannot be used to: - Create cleaning tasks - Assign cleaning staff - Update cleaning status These functions must be implemented and managed within your own system.

About the Fee-Related Fields in RoomReservation

Important Specifications and Integration Considerations for fee_breakdown / per_day

The room_reservation.fee_breakdown returned by Stay/Public API contains the daily amount record with type = per_day , and the sum of multiple per_day amounts is consistent with accommodation_fee .

Topic	Description	Reason
Relationship Between `per_day` and `Net Room Fee`	`per_day` represents the daily room charge. However, it is not always a net room fee. If there are fee items with `include_in_per_day_fee` = true, those amounts are already included in per_day, making it a gross value. To calculate the net room fee, such included fees should be subtracted.	Some fees (e.g., service fees) may be bundled into the room rate depending on configuration, so `per_day` can represent either net or gross values.
API Specification Support for `per_day` and fee_breakdown	It is a formally supported field defined in the Public API specification.	This ensures that integrators can safely rely on this field for implementation.
Availability Across Channels and Sources	`per_day` is returned regardless of channel or source, including Booking.com, other OTAs, manual reservations, and rate plans.	The API maintains a consistent data structure across different reservation sources.
Impact of Reservation Status on `per_day`	The presence of `per_day` depends on whether the room charge line has been voided: • OTA cancellations: room charge is usually voided → `per_day` becomes empty • Manually created / user-cancelled reservations where the room charge line is not voided: `per_day` items are still returned after cancellation.	Different cancellation flows (OTA vs manual) handle financial line items differently, affecting whether `per_day` is retained.
Relationship Between `per_day` and Other Fees (e.g., `cleaning_fee`, `channel_fee`)	`cleaning_fee` and `channel_fee` are always listed as separate line items. However, whether they are included in `per_day` depends on `include_in_per_day_fee`: • false → separate from per_day • true → already included in `per_day`	Fee configuration determines whether charges are itemized separately or bundled into the room rate.