[AirHost API] FAQ for Implementing the Internal System

Category

Description

Standard Guest Count Fields

ChildA–ChildD Fields

child_a_count~ is a value derived child_d_countfrom the age categories used in the Japanese hotel and inn industry .child_count

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:

However, children under 3 years old and over 12 years old are not included in Child A-D.

[example]

in the case of:

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_countmay 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_countChildC and ChildD are also included in that category.

Therefore, child_a + child_b + child_c + child_d > child_count　this may occur.

[Notes]

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.

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.

Topic

Description

Reason

booking_fee only accepts a total amount

room_reservation.booking_fee is a single number field representing the total accommodation charge for the entire stay.
It cannot be broken down by night at creation time.

This is a current limitation of the Public API specification for reservation creation.

How the total is applied to each night

AirHost automatically splits the submitted total evenly across the number of nights to populate the reservation's per-night pricing.

This averaged value is what's shown in the reservation order details, and is also the value used to calculate AirHost's automatic accommodation tax.

Because no per-night rate is submitted, the system has no other basis for populating a nightly breakdown.

charges is not a substitute for per-night rates

charges[] (fee_type: booking_fee / dining_fee / cleaning_fee / cancellation_fee / other_fees) is designed to record individual billable items
(e.g. dining, cleaning, cancellation fees), not to specify nightly room rates.
​
Even if you submit one charges entry per night with a date and amount, this data is only reflected in the transaction/invoice records — it is not written back into the reservation's own per-night pricing, and does not affect the automatic accommodation tax calculation.

charges was designed around AirHost-collected miscellaneous fees. Treating it as a substitute for nightly rates would affect other integrators who use charges for its intended purpose without submitting per-night data.

Impact on accommodation tax

Since AirHost's automatic accommodation tax calculation is based on the same per-night pricing derived from booking_fee, the tax amount will also be calculated using the averaged nightly rate, not the actual rate for each night — which may produce different results in municipalities that apply per-person, per-night tax brackets (e.g. Osaka).

The tax calculation reads from the same underlying per-night data as the reservation record.

Current workaround

If accurate per-night pricing and tax amounts are required, this currently needs to be handled manually:
(1) manually correct the auto-generated accommodation tax amount, or
(2) create the reservation manually via the AirHost UI instead of via the API.

There is no way to resolve this automatically via the API at present.

Payment amount

( payments[].amount)

This is the total booking amount charged by the OTA to the guest. It is not the actual transfer amount (net amount) remitted by the OTA to the property after deducting fees.

Settlement date

( payments[].date)

This is the date on which the payment data was created in AirHost. It is not the actual date on which the OTA transferred the funds.

How to check OTA fees

OTA fees are not included in payments[].amount. If fee data is provided by the channel, you can check it in the channel_fee field of the Booking Details API (GET /room_reservations/{id}).