Overview

Explore our recommended step-by-step process depicted in the workflow diagram below, guiding you through project execution and optimization.

📘

Please be aware that while this is a commonly used implementation workflow, it is not the sole method considered acceptable for execution. This workflow outlines the process for a number of the most common API implementations.

🔁 Caching Best Practices

To optimize performance and reduce unnecessary API calls, implement intelligent caching strategies based on available timestamps. Below are best practices for caching different data types:

🗓 Availability Data

• Preferred Method: Use the /unit_calendars endpoint with the last_reservation_update_date parameter to fetch availability data only for units that have changed since your last sync.
• Fallback Option: If filtering by timestamp isn’t feasible, cache availability data in bulk and refresh it for all units 1–4 times per day based on your inventory size and change frequency.
• Tip: A timestamp-driven delta sync helps reduce load and ensures you’re only updating the properties that need it.

🏡 Unit Data

• Preferred Method: Utilize the last_unit_update_date parameter from the /units endpoint to detect changes since your last sync. Refresh data only for units where this timestamp has changed.
• Fallback Option: If using timestamps isn't feasible, cache unit data and refresh it on a fixed interval. Ideally, once daily, but weekly or bi-weekly may suffice depending on your business needs.
• Tip: Avoid mapping all units on every sync. Use a delta-based approach where possible to minimize API usage and improve performance.

📋Unit Details

• Preferred Method: Since unit details (e.g., amenities, descriptions, images, etc.) are polled from different endpoints, use the last_unit_update_date parameter from each respective endpoint to rebuild details only for units that have changed.
• Fallback Option: Rebuild unit details for all units on a daily, weekly, or bi-weekly cadence, depending on your business needs.
• Tip: For bulk updates or internal search indexing, consider queue unit rebuilds during off-peak hours (e.g., 1900 - 0700 Eastern Time) to reduce load during high-traffic periods.

📅 Reservation Data

• Preferred Method: Use the modified_start and modified_end parameters on the /reservations endpoint to fetch only reservations that have been added or updated since your last sync. Query for updated reservations using a rolling modified_start timestamp (e.g., "last checked time") and a current timestamp as modified_end.
• Fallback Option: If not using timestamps, retrieve all recent reservations in a rolling window (e.g., last 7–14 days), ideally every 1–3 hours.
• Tip: Store your last successful sync time and use it as modified_start for the next request to minimize duplication. Handle paging and updates carefully for overlapping changes.