EDistribution API

Sell Elivaas stays from your own product#

Search live inventory, price a stay to the paisa, book it against your credit line, and settle monthly by GST invoice. No card, no checkout, no logging into anyone else's dashboard — twenty-five HTTP endpoints and a key.

The shape of a sale#

Four calls, always in this order. Each one is a separate page in these docs.

  1. Find something to sell — and this is the one choice you make#

    Either we hold the index and you call POST /v1/listings/search, or you hold it: sync availability, rates and inventory with GET /v1/listings, GET /v1/availability and GET /v1/rates, and run discovery in your own store.

    Path A is faster to launch and always current. Path B gives you your own ranking and merchandising, at the cost of owning freshness. Everything after this step is identical either way, so the decision is reversible.

    Choose a path → · A · Use our search · B · Cache ARI

  2. Price it#

    POST /v1/orders returns a priced order — the exact grand total, tax and cancellation terms the booking will use. Nothing is held and nothing is charged.

    Pricing and ordering →

  3. Book it#

    POST /v1/bookings turns that order into a real booking, charged against your credit line. You pass the total you are accepting; a price that moved underneath you is rejected rather than silently charged.

    Booking on credit →

  4. Settle it#

    Charges accumulate on your ledger and become GST invoices on your billing cycle. You pay the invoices, not the bookings.

    Invoices and paying →

Three things that surprise people#

Worth knowing before you write code, because each one changes how you design your integration.

Your account#

Your account is the entity we contract with and bill: a travel agency, an OTA, a corporate travel desk, a reseller. It carries your channel, your credit limit, your billing cycle and usually your GSTIN.

Every request is scoped to it, and your API key is what identifies it. You never send an account id, a channel id, an agent id or a user id — there is no field for one on any payload, and none would be honoured if you invented it.

Environments#

Two environments, one contract. The API, the field names and the error envelope are identical — only the data and the keys differ.

Base URL
Sandboxhttps://sandbox.partner-api.elivaas.comTest data. Bookings here are not real, cost nothing and never reach a property
Productionhttps://partner-api.elivaas.comLive inventory. A booking is a real stay and a real charge against your credit line

Keys are per environment and not interchangeable. A sandbox key sent to production is a 401, and so is the reverse — the same 401 you get for a revoked key, by design. Ask for a sandbox key during onboarding and integrate against it; move to production once your flow survives the errors you should expect.

Conventions#

Base URLhttps://partner-api.elivaas.com (production). Build against sandbox first
VersioningEvery path is under /v1. No tenant segment, no other prefix
Content typeJSON in, JSON out — except GET /v1/invoices/{id}/pdf, which returns application/pdf
DatesISO 8601. Plain dates (2026-08-10) for stay dates, instants (2026-05-21T11:09:03.024811Z) for timestamps
Bulk firstRead endpoints take lists of ids and date ranges. They are designed so you never loop one listing or one date at a time
MoneyCatalogue, rate, search and promotion feeds quote integers in paise. Order, booking, ledger and invoice figures are decimal rupees. Every field says which — do not assume across endpoints
ErrorsOne envelope for every failure. See Errors

The OpenAPI spec#

code
https://partner.elivaas.com/openapi/distribution.json

Generated from the running service, and the same source the API reference on this site is built from — so the two cannot disagree. Point your client generator at it.

Getting help#

api@elivaas.com. Include the path and timestamp from any error body; both are in every failure response and are enough for us to find the request.