📆 ARI Flow (Availability, Rates & Inventory)

The ARI Flow describes how external systems (Booking Engines, RMS, Channel Integrators, PMS partners, etc.) retrieve and update availability, prices, and restrictions in Octorate using the officially

🧭 Flow Overview

Step	Action	Endpoint	Description
1	Retrieve inventory (rooms & rate plans)	GET /rest/v2/roomrates/{accommodation}	Load product structure
2	Retrieve current ARI	GET /rest/v1/calendar/{accommodation}	Get prices, availability, restrictions
3	Update ARI in bulk	POST /rest/v1/calendar/bulk	Push availability, prices, restrictions
4	Retrieve ARI processing failures	GET /connect/rest/v1/calendar/failures	Check if push succeeded
5	(Optional) Check availability	GET /rest/v1/calendar/{accommodation}/{productId}/availabilityCheck	Validate bookability
6	(Optional) Create/Update products	POST /connect/rest/v1/roomrates/{accommodation}/{roomId}	Manage rooms & rates

---

🏨 Step 1 — Retrieve Room & Rate Inventory Structure

Before pushing ARI, you must understand the product structure (rooms, rate plans, derived rules).

Endpoint

GET /rest/v2/roomrates/{accommodation}

What you get

• Base rooms

• Derived rates (with derivation rules)

• Availability relationships

• Price inheritance

• OTA visibility

• Policies connected to each rate

This defines exactly which product IDs you can update in ARI.

---

📥 Step 2 — Retrieve Current Availability & Rates

Endpoint

GET /rest/v1/calendar/{accommodation}

Purpose

• To display availability & prices in a booking engine

• To allow an RMS to build pricing strategies

• To audit the property’s current ARI state

You receive (per day × product)

• price

• stock / availability

• minStay, maxStay

• closeToArrival, closeToDeparture

• stopSell

(Exact fields depend strictly on OpenAPI; I only include documented ones.)

---

🔧 Step 3 — Push ARI Updates (Availability, Prices, Restrictions)

This is the core ARI operation.

Endpoint

POST /rest/v1/calendar/bulk

Supports updating:

• Availability

• Price

• Min/Max Stay

• Close to Arrival / Departure

• Stop Sell

• Cut-off days

• Multiple rooms × multiple days (bulk)

Example Payload

(Structure based on your OpenAPI)

[
  {
    "room": 397201,
    "dateFrom": "2025-01-01",
    "dateTo": "2025-01-05",
    "values": {
      "availability": 2,
      "price": 120,
      "minstay": 2,
      "closedToArrival": false,
      "closedToDeparture": false
    }
  }
]

Response

The API returns a process ID used for checking failures.

---

🔍 Step 4 — Retrieve ARI Failures (Validation)

After sending ARI updates, you must check if every update succeeded.

Endpoint

GET /connect/rest/v1/calendar/failures

Purpose

Retrieve the list of failed ARI updates for your account, including:

• invalid date ranges

• invalid product IDs

• OTA mapping errors

• pricing inheritance conflicts

• policy restrictions

This replaces older /process/{id} calls.

---

🧪 Step 5 — Check Availability (Validation)

Useful for booking engines to confirm a product is sellable.

Endpoint

GET /rest/v1/calendar/{accommodation}/{productId}/availabilityCheck

Behavior

• 200 OK → available

• 406 Not Acceptable → not available (CSR-like logic)

---

🧱 Step 6 — Create or Update Room/Rate Products (Optional)

If you need to manage inventory programmatically:

Create/Update Product

POST /connect/rest/v1/roomrates/{accommodation}/{roomId}

Used for:

• adding new rooms

• adding new rate plans

• updating derivation rules

• setting adult/child policies

• setting availability/price inheritance

Create Suite

POST /rest/v1/roomrates/{accommodation}/{product}/suite

---

⚠️ Error Handling

HTTP	Error	Meaning
400	Invalid parameters	Bad date range, invalid values
401	Unauthorized	Token missing or wrong
403	Forbidden	No rights for this accommodation
404	Not Found	Product not found
500	Server Error	Octorate-side issue

---

💡 Best Practices

• Always load /roomrates before pushing ARI.

• Use bulk to send all updates (more efficient).

• Check the failures endpoint after every ARI push.

• Do not push more than 31 days per request unless allowed.

• Respect rate derivation logic (don’t overwrite derived children).

• Retrieve availability before quoting a price.

• Use UTC or ISO dates as documented.

---

🧭 ARI Flow Summary

Step	Description	Endpoint
1	Load inventory structure	GET /rest/v2/roomrates/{accommodation}
2	Read current ARI	GET /rest/v1/calendar/{accommodation}
3	Push ARI	POST /rest/v1/calendar/bulk
4	Validate push	GET /connect/rest/v1/calendar/failures
5	Check availability	GET /rest/v1/calendar/{accommodation}/{productId}/availabilityCheck
6	(Optional) Create/Update products	/connect/rest/v1/roomrates/{...}