---
updatedAt: 2025-09-09T21:11:55.000Z
agentTools:
  projectIndex: https://docs.ciiruspartners.com/llms.txt
---

# Suggested Workflow

Suggested Workflow Page with Workflow Diagram

# Overview

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

<Image alt="Click image to view larger." align="center" border={true} src="https://files.readme.io/b549bd5ad1b14530190a0edfa005d5deadf45f9ba8233451cabd54f7f3d1d03c-CiiRUS_API_-_Booking_Partner_Workflow_4.png">
  Click image to view larger.
</Image>

> 📘
>
> 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.