Skip to main content
Omnibeds is a travel agency platform that searches several hotel suppliers at once, merges what they return into one list, and lets agents quote, book and look after bookings. These pages explain how the code is organised and what happens, step by step, in each of the main flows. They are written for the team that builds and runs it.

The idea in one paragraph

Every action on travel data, such as cancelling a booking or adding an option to a quote, is a command with a name, a risk level and its own checks. Screens call commands through one typed client. Commands use the domain services, and the services talk to suppliers through one shared adapter contract. Because the rules live in the commands and not in the screens, a person, a scheduled job and later an AI assistant all get the same checks. Click a layer to see what it does and where it lives.

Find your way

Architecture

The layers, commands and their checks, the data, and how screens call the server.

Pipelines

Search, booking, quotes, changes after booking, and the background jobs.

Suppliers

The adapter contract, how each supplier keeps state, and confidential suppliers.

Operations

Error format, traces, health, and how the code is tested.

Rules that apply everywhere

Booking, rebooking, switching to a cheaper rate and cancelling are always started and confirmed by a person. The background jobs only check and flag; they never book or cancel on their own.
Each supplier documents what it accepts, for example which characters a guest name may contain. Omnibeds checks those rules first and shows them in the screen, so a request the supplier would refuse is never sent.
Some suppliers’ terms treat their data as confidential. Their results, bookings and logs are only served when presenter mode is unlocked. See Confidential suppliers.
A booking page always asks the supplier how it holds the booking now. Fields that only our database knows are labelled “Omnibeds DB”. See After booking.