Why TravelCore
Explore twenty decisions behind TravelCore, from supplier connectivity to commercial control. Each one links to a guide, demonstration or explanation you can inspect.
01–05
The claims we refuse to make. This is the category most travel platforms compete in by exaggerating; we compete in it by not.
Live, design-partner preview or roadmap is printed on every module, API and template across the site — including the ones that are not built.
Flights, transfers, activities and payments are listed as 'not live' on our own status page, and we explain why no uptime chart is published yet.
Our security page names what we do not hold — no SOC 2, no ISO 27001, no completed penetration test — in the same list as what we do.
We do not publish a hotel count. Coverage is the union of the suppliers you are contracted with, and market figures are attributed to the aggregators who publish them.
Our build scenarios say plainly that they are illustrative and that no reference customer exists.
06–10
What happens between your search box and seven supplier APIs that each behave differently.
Searches fan out in parallel with a per-supplier time budget. Suppliers that miss it are reported by name in the response and the result is marked `partial: true`.
Property matching scores candidates into three bands — auto-merge, reject, and a review queue for the uncertain middle — and the engine runs live on our own site, so you can move the thresholds and watch the bands change.
Agreeing on the hotel does not mean agreeing on the room. Room descriptors run through a separate matching stage with its own attributes, its own hard conflicts — a king is never a twin, an accessible room is never a standard one — and its own review queue.
When a supplier burns through its budget, the platform drops it from the search fan-out rather than letting it drag every search down.
p50, p95 and p99 per supplier, plus the share of searches each one actually answered in time.
11–14
The failure modes that cost real money — duplicate bookings, phantom bookings, repriced rates — and how each one is closed.
Booking intent is journalled before the supplier is contacted, then reconciled by querying with your client reference until the true state is known.
There is a required call that re-checks the chosen rate against the supplier immediately before money moves, and it tells you whether the price held.
Not offered, required. Replaying a key returns the original booking with an explicit `X-Idempotent-Replay` header instead of creating a second one.
A policy is an array of absolute deadlines and amounts, not a sentence for your front end to parse.
15–17
Margin, credit and price, treated as data you can audit rather than logic you deploy.
Markup, commission, tax and fees are rules with versions and effective dates. The computed breakdown is stored on the booking, not recomputed on read.
An agent at its limit is stopped at the point of sale. The check happens in the booking path, not in a monthly review.
No price list. We name the three variables that actually move your cost — look-to-book, supplier mix and surface area — and quote against them.
18–19
The Middle East and North Africa as the first market, not as a localisation ticket.
Our RTL templates are laid out right-to-left from the grid up — search panel, price alignment, icon direction, form flow — then work in LTR. Not the reverse.
Dated programmes, fixed departures, distance to the Haram as a first-class attribute, visa and document checklists, family booking as the default path.
20–20
What you are actually shown before you buy.
Fourteen templates are real components reading theme variables, which is why one palette click repaints all of them at once — by the same mechanism that themes a real tenant.
The twenty-first
If what you need is on our roadmap, or if you would be better served building it yourself, you will hear that on the first call. It is the cheapest thing we can give you and the rarest thing in this category.