Choose an integration path#
There are two ways to build on this API, and it is worth choosing deliberately before you write code.
The choice only affects how you find inventory. Pricing, booking, amending, cancelling and settling are byte-for-byte identical either way.
Path A — Use our search
We hold the index. You call POST /v1/listings/search and GET /v1/filters and show what comes back. Fastest to launch, nothing to keep fresh.
Path B — Cache ARI
You hold the index. Sync availability, rates and inventory into your own store and run discovery yourself. Full control over ranking and merchandising.
Where they differ, and where they don't#
Path A search + filters ─┐
├─▶ order ─▶ book ─▶ ledger ─▶ invoice
Path B your own index ─┘Everything to the right of that join is one code path. You can also change your mind later without rewriting your booking flow — swapping discovery does not touch anything downstream.
| Path A — our search | Path B — cache ARI | |
|---|---|---|
| Who runs discovery | We do | You do |
| Endpoints | POST /v1/listings/search, GET /v1/filters | GET /v1/listings, GET /v1/availability, GET /v1/rates |
| Storage you operate | None | A catalogue, an availability calendar and a rate store |
| Freshness | Always current — you read it live | Yours to maintain. Stale data is your bug |
| Ranking and merchandising | Ours | Entirely yours |
| Filters | The facets your channel exposes | Anything you can index |
| Search latency | A network call per search | Whatever your own store does |
| Works offline / behind your own cache | No | Yes |
| Request volume | One per search | A few per sync, then none |
| Time to first booking | Hours | Days |
Which one are you?#
Take Path A if you are adding Elivaas stays to an existing product, you want to be live this week, your search volume is modest, or you would rather not own a sync pipeline. It is the right default, and it is what the Quickstart walks through.
Take Path B if you run your own search and ranking, you sell across suppliers and need one unified index, you need Elivaas inventory to appear in results you compute yourself, or your search volume would make a call-per-search impractical.
What Path B commits you to#
Worth being honest about, because these are the parts people underestimate:
Keeping the catalogue current#
GET /v1/listings?updatedSince=…is an incremental feed. You have to run it on a schedule and handle the case where a listing disappears from your channel.Keeping availability current#
Availability changes constantly and without warning — other channels are selling the same rooms. A nightly sync is not enough for anything close to real time.
Accepting that your prices are indicative#
Whatever you cached, the binding figure comes from
POST /v1/orders. You must reprice before booking, and be ready to show a customer a number different from the one they clicked. See pricing.Owning the failure mode#
A stale cache sells a room that is gone. The booking fails rather than overselling — but your customer has already chosen it, and that is your experience to design.