> ## Documentation Index
> Fetch the complete documentation index at: https://demo-travel.webbinghub.io/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Omnibeds: how the platform is built and how it works

> Omnibeds connects a travel agency to several hotel suppliers at once. This guide explains its layers, its pipelines and the rules that keep them safe.

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.

Each layer only calls the one below it. A test fails the build if a screen imports server code or calls a command's URL by hand.

## Find your way

> [card] [Architecture](https://demo-travel.webbinghub.io/docs/architecture/layers.md)
>
> The layers, commands and their checks, the data, and how screens call the server.

> [card] [Pipelines](https://demo-travel.webbinghub.io/docs/pipelines/search.md)
>
> Search, booking, quotes, changes after booking, and the background jobs.

> [card] [Suppliers](https://demo-travel.webbinghub.io/docs/suppliers/adapters.md)
>
> The adapter contract, how each supplier keeps state, and confidential suppliers.

> [card] [Operations](https://demo-travel.webbinghub.io/docs/operations/errors-and-logs.md)
>
> Error format, traces, health, and how the code is tested.

## Rules that apply everywhere

> [accordion] Nothing that costs money happens without the agent
>
> 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.

> [accordion] Supplier rules are checked before we call them
>
> 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.

> [accordion] Confidential suppliers stay behind presenter mode
>
> Some suppliers' terms treat their data as confidential. Their results, bookings and logs are only served when presenter mode is unlocked. See [Confidential suppliers](https://demo-travel.webbinghub.io/docs/suppliers/confidential.md).

> [accordion] The supplier is the source of truth for a booking
>
> 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](https://demo-travel.webbinghub.io/docs/pipelines/after-booking.md).

| Layer | What it does | Where it lives |
| - | - | - |
| Screens | Pages and components the agent uses | `app/(app)`, `components/` |
| Typed client | One function, `api(name, input, doing)`, for every command | `lib/client/api.ts` |
| Routes | One line per route, turns HTTP into a command call | `app/api/**/route.ts`, `lib/app/http.ts` |
| Commands | Name, risk, input schema and checks for each action | `lib/app/command.ts`, `lib/app/commands/` |
| Domain services | Search, booking, quotes, trips, pricing | `lib/orchestrator`, `lib/booking`, `lib/quotes`, `lib/trips` |
| Supplier adapters | One contract for every supplier | `lib/suppliers/` |
| Data | Postgres, migrations, agency scope | `lib/db`, `lib/tenancy` |


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.