EDistribution API

Path B — Cache ARI#

Pull Availability, Rates and Inventory into your own store, run search and ranking yourself, and call us only to price and book.

You do not need POST /v1/listings/search or GET /v1/filters at all on this path — you are replacing them with your own index. See choosing a path for the trade-off.

Three feeds:

IGET /v1/listingsThe catalogue, with an incremental feed
AGET /v1/availabilityOne row per property per night
RGET /v1/ratesNightly pricing in bulk

Inventory — the catalogue feed #

GET /v1/listings is the feed to build the pipeline around.

Three parameters, and they combine with AND — none is ever ignored.

updatedSince returns only rows changed at or after an instant. This is the incremental feed and the one that makes a routine sync cheap.

listingIds fetches a specific set, up to 100. Supplied without an explicit size, the page holds the whole requested set, so an id lookup never needs paging.

cursor and size page the result.

First full sync
curl -G "$BASE/v1/listings" -u "$ELIVAAS_API_KEY:" \
  --data-urlencode 'size=100'
Every sync after that
curl -G "$BASE/v1/listings" -u "$ELIVAAS_API_KEY:" \
  --data-urlencode 'updatedSince=2026-07-28T00:00:00Z' \
  --data-urlencode 'size=100'

Paging correctly#

code
page 1 → nextCursor: "eyJ..."   → keep going
page 2 → nextCursor: "eyJ..."   → keep going
page 3 → nextCursor: null       → done

Loop until nextCursor is null. A short page is not the end of the data — treating it as one truncates your catalogue, and you will not notice until someone reports a missing property.

Listings that disappear#

updatedSince tells you what changed, not what was removed from your channel. A listing withdrawn from your channel simply stops appearing.

Reconcile periodically: run a full sync (no updatedSince) on a slower schedule — weekly is usually enough — and deactivate anything in your store that the full pull did not return. Without this, withdrawn inventory stays sellable in your index and produces booking failures nobody can explain.

Availability #

GET /v1/availability returns one row per property per night.

Ask for the whole range in one call. Up to 100 ids and a 365-day window, precisely so you never loop a date.

A night absent from the response is a night with no inventory. There is no explicit "closed" row — absence is the signal, and a naive merge that only overwrites the nights it received will leave sold-out nights looking available forever. Clear the range before applying the response.

Scope by listingIds or propertyIds: a listing can hold several bookable properties, and availability is tracked per property.

cURL
curl -G "$BASE/v1/availability" \
  -u "$ELIVAAS_API_KEY:" \
  --data-urlencode 'listingIds=lst_0853ie' \
  --data-urlencode 'listingIds=lst_19bkq2' \
  --data-urlencode 'from=2026-08-01' \
  --data-urlencode 'to=2026-10-31'

Rates #

GET /v1/rates returns nightly pricing in bulk. Two shapes:

from / to — a calendar range, for painting a price calendar into your store.

checkIn / checkOut — a specific stay.

promotionMode controls whether promotional pricing is reflected.

For a sync you want the calendar form, over the same horizon as your availability pull.

Calendar range
curl -G "$BASE/v1/rates" -u "$ELIVAAS_API_KEY:" \
  --data-urlencode 'listingIds=lst_0853ie' \
  --data-urlencode 'from=2026-08-01' \
  --data-urlencode 'to=2026-10-31'

A sync that behaves#

  1. Seed the catalogue once#

    Full GET /v1/listings, paged to the end. Store the start timestamp.

  2. Then run it incrementally#

    updatedSince on a schedule. Cheap, and the cadence can be minutes.

  3. Refresh ARI on a horizon-aware cadence#

    Near dates often, far dates rarely. Availability moves faster than rates, and both move faster than the catalogue.

  4. Clear before you apply#

    For an availability range, delete the window before writing the response — absent nights mean unavailable, and a merge that only writes what it received cannot express that.

  5. Full-reconcile on a slow schedule#

    Weekly. Deactivate anything a full pull did not return; that is the only way withdrawn inventory leaves your index.

  6. Reprice before you book, always#

    Your cache is for discovery. POST /v1/orders produces the figure that binds.

The rule this path lives under#

Also cache cannot tell you a room is still there. Availability you pulled ten minutes ago can be gone. The booking will fail rather than oversell — but the customer has already chosen it, so decide what that experience looks like.

What you still call live#

Even on this path, these are never cached:

POST /v1/ordersThe binding price
POST /v1/bookingsThe booking itself
GET /v1/statementYour credit headroom
Everything after the bookingAmendments, cancellations, ledger, invoices

Next#

Your index is built. Price a stay — from here the two paths are identical.