Which reservations NextPax can and cannot import during migrations and channel takeovers

During a migration or channel takeover, NextPax imports existing reservations directly from the channel's API. The core principle is the same for every channel: NextPax can only import reservations that the channel actually exposes to us through its API. What is retrievable beyond that depends on the individual channel.

Conditions that apply to every channel

For any reservation to be imported, the property must be correctly connected to NextPax as the connectivity provider on that channel, and the channel listing must already exist and be mapped in NextPax. A reservation can only be attached to a listing that exists on the NextPax side: if the listing has not yet been onboarded into NextPax — meaning there is no corresponding NextPax property to link it to — the reservation cannot be imported until the listing is created and mapped. If the property is not correctly connected, the channel will not release its reservations to us at all; Booking.com, for example, returns a 403 Forbidden with "hotel reservation does not belong to any of provider's hotels." These are property-side configuration issues that must be resolved (connection and mapping) before the reservations can be retrieved.

Booking.com — additional limits

For Booking.com, reservations are retrieved through the channel's reservations summary endpoint. This endpoint only returns reservations with a check-out date in the future, and it does not include cancelled reservations. As a consequence, on Booking.com:

• Past reservations — stays already consumed before the migration — are not retrievable and are not imported.
• Cancellations that occurred before the migration are not surfaced through the reservation summary, so they are not picked up automatically during the import.

This is a limitation of the Booking.com API itself: Booking.com does not provide past or cancelled reservations in the reservation summary, so NextPax cannot import what it is not given.

Expedia and Vrbo

For Expedia and Vrbo this restriction does not apply: NextPax is able to import past and cancelled reservations as well. In practice a sensible cut-off is applied rather than importing the entire history, so the import stays focused on reservations that are still relevant.

How the import handles large volumes

NextPax imports reservations through a queued, asynchronous pipeline that is built around the channels' own API limits. Channel reservation APIs apply rate limits and batch-size limits — for example, retrieval is paginated and mutation batches are capped (Vrbo, for instance, limits a batch to 100) — so NextPax queues reservations and processes them in controlled batches rather than all at once. This is a deliberate design that keeps large migrations, often involving thousands of reservations, stable and reliable while staying within each channel's limits, and it scales cleanly as portfolio and migration sizes grow. Continuous improvements have also been released to further reduce missing reservations and duplicates. These mechanics govern throughput and timing only; they do not change which reservations are retrievable — that is still determined by the channel API boundaries described above.

Practical guidance for migrations and takeovers

Before a takeover, make sure every property is correctly connected to NextPax as the provider and that all listings are mapped in NextPax, so reservations are not rejected (for example with a 403 on Booking.com). When reconciling afterwards and a reservation is expected but missing, the first checks are whether the property is connected, whether the listing is mapped, and whether the channel actually returns the reservation through its API — if the channel does not return it, NextPax cannot import it. For Booking.com specifically, also check whether the reservation has a future check-out date and whether it was cancelled, since past and cancelled reservations are not provided by Booking.com's reservation summary.