Skip to main content
Omnibeds connects to LiteAPI (by Nuitee) version 3 over REST and JSON. LiteAPI’s flow is chained: a search returns an offerId, a prebook turns it into a prebookId, and the booking uses that. In the sandbox, bookings paid with ACC_CREDIT_CARD are simulated and nothing is charged. The adapter is in lib/suppliers/liteapi/.

At a glance

Their flow and ours

Must do

1

Prebook before every booking

LiteAPI always wants a prebook first. Omnibeds prebooks again at booking time, so the booking always uses a fresh prebookId.
2

Search with the guests' residence

Every search sends guestNationality: the search’s residence field, else the agency’s default residence, else its country.
3

Describe the place one way

One of: the hotels by id, a known city by country code and city name, or a circle around any place (latitude, longitude, radius in metres). Each search asks for up to 20 hotels and 8 rates per hotel, in EUR, with an 8 s timeout.
4

Give an email per room

LiteAPI wants a holder email and a guest per room. Omnibeds uses the agency’s contact email and the holder’s name for each room.
5

Keep the pace

Every live call waits for its turn under 4 a second and passes the daily cap. When LiteAPI still throttles, Omnibeds waits as asked (at most 2 s) and tries once more.

Never do

  • Never spend the key on a health check: health makes no call.
  • Never let Replay call LiteAPI. Replay answers from recordings kept on this machine, outside git; without a recording the call fails and says so.
  • Never change other guests’ names or who travels through amend: it only changes the holder.

How its data becomes ours

When something goes wrong