Booking.com and Agoda API synchronization remains the existing Advanced Integration module. This is the existing Advanced Integration surface that operators should continue to use for API reservations. #0170.6 documents its boundary so iCal does not replace or refactor it. API credentials, room mapping, webhooks, reservation imports and their scheduler retain the previously accepted contract.
Keep the modules separate
- Open the existing Hotel Booking → OTA Sync API area and use its provider settings for Booking.com or Agoda.
- Keep API credentials in the API credential fields; never paste them into an iCal source form.
- Use the API module’s mapping and reservation workflow for reservations that arrive through its provider connection.
- Use a room’s OTA Sync tab and iCal Calendar Sync only for calendar feeds that do not use the API reservation contract.
An API reservation is a normal booking record with the provider source label. An iCal event creates an external block with no guest or payment details. Do not import the same reservation through both paths; choose one authoritative source and document that choice for staff.
The iCal scheduler is separate from the API scheduler. A change to iCal source health, token rotation or parser behavior must not alter API mappings or webhook semantics. If an API issue appears after an iCal change, capture the provider, job ID, mapping and redacted error independently and use the existing API support path. No API refactor or credential migration is part of this documentation phase.