A single platform for booking hotels, cars and transfers

The project turned an outdated Joomla website with unstable integrations into a modern Frapi‑based travel platform. Instead of disparate forms and manual support, a three‑tier architecture has been created with a unified API layer, personal accounts, dozens of suppliers, and a full-fledged hotel service. The result is a single account for all types of bookings, high reliability and ready to scale.

When we connected:

• the main site already existed on Joomla
• car rental and transfer services have been implemented, but not unified
• integrations with suppliers were unstable
• scaling was limited by architectural constraints
• there was no unified system of personal accounts and favorites

The project required not to refine individual functions, but to completely rethink the architecture and approach to development.

By the time the decision to redesign and rebuild was made, the brand had set goals:

• Increase online sales through three products: hotels, cars, transfers
• create a single platform, rather than a set of disparate forms
• increase stability and speed of work under load
• give the user a personal account, favorites, and collections
• lay down an architecture that will make it easy to connect new suppliers

In fact, to build a travel ecosystem from scratch on top of existing external APIs.

The project has been completely redesigned. Instead of point-to-point support, we designed and implemented a new Frapi-based system.

The modern client part:

• the main page with the main block and a universal search module with three tabs: Hotels, Cars, Transfers
• result pages with filters, sorting, cards and a map
• detailed object pages with gallery, description, conditions, and reviews
• adaptive layout for computers, tablets, and mobile devices

A full-fledged personal account:

• a desktop with upcoming trips
• My reservations section with a filter by type: hotels, cars, transfers
• «Favorites» for each type of object
• Collections: the user can create lists, for example, «Summer vacation» or «Trip to Spain»
• Profile editing: name, email, phone, password

Multilevel architecture based on Frapi. Our own scheme has been developed and implemented:

The client part of the site →
Search logic, aggregation, cache, filters →
Rentaholiday API level on Frapi, unification of data from different suppliers →
External APIs for hotel, car, and transfer providers

The client side only works with its API, receiving a single format of requests and responses. Different vendors with different data structures are brought to a single model. The search for hotels, cars, and transfers goes through separate endpoints. Adding a new provider does not break the client side — it is enough to write an adapter at the API level.

New services and pages. The transfer service has become a full-fledged product, not an additional option.

Landing pages for search engine promotion:

• city pages for hotels
• airport pages for cars with clarifications, for example cheap, no deposit, with automatic transmission
• transfer route pages

Category cards on the landing pages: popular destinations, best deals, categories.

The booking process. A clear four-step route:
Search → Selecting an object → Data entry and payment → Confirmation with the booking number.
Different types of confirmation are implemented depending on the provider: instant booking, on-demand booking, and post-processing confirmation.

The Admin Panel:

• Booking management: view, search, status change
• Content management: hotels, cars, transfers
• user management
• editing texts for search promotion with up to 3,000 characters for each significant page

The total number of connected providers exceeds twenty, but the approach has been completely changed.
Instead of direct integrations from Joomla and constant bug fixes, a single API layer has been created on Frapi, which:

• brings the fields of any supplier to the internal model
• handles differences in currencies, fees, and service level agreements
• centrally records errors and timeouts

The connection time of the new supplier has been reduced from three to four weeks to three to five days. Any change to the external API is corrected in one place, not in dozens of scripts.

The new architecture made it possible to implement:

• multi-level caching of search results and static pages
• monitoring parallel requests to external APIs
• a queue for processing long requests, for example, for delayed confirmation
• Fault tolerance: If one provider is unavailable, results from the rest are shown.

With traffic of about 50,000 visitors per month and peak seasonal spikes, the system consistently delivers results in an average of two seconds for hotels and one and a half seconds for cars and transfers.

Hotels have become the most difficult segment.
Implemented entirely on the Frapi server side.
The hotel database is accessed via external APIs, but room availability, final price calculation, filtering and order management are done on our side. Added filters by stars, rating, distance, and amenities. The number of hotels in search results reaches tens of thousands, and pagination and filtering work without delay.

Now it’s not a separate product, but part of a single account. One user books a hotel, then a car and a transfer — all data is saved in one profile.

Booking conversion increased by about 37 percent thanks to the user-friendly search module and personal account.

Repeat bookings have increased — users are returning to their favorites and collections.

Armor operations are completely transparent to the client: cancellation and modification are available through the personal account.

The brand has ceased to be a car rental service and has become a real travel platform with hotels, cars and transfers.

Traffic from search engines has grown due to hundreds of new landing pages: cities, airports, combinations like «cheap hotels in Barcelona».

Unification of data from dozens of external APIs
One supplier sends the price with taxes, the other without. One gives instant confirmation, the other two hours later. The API layer on Frapi solves this problem, but it required careful design.

Booking status model
Statuses may vary for hotels, cars, and transfers. A general scheme has been developed: waiting → confirmed → completed / cancelled / not completed.

Transferring users from the old system
I had to transfer my booking history and accounts from Joomla to the new database. A script has been written to remove duplicates and verify data integrity.

Real-time price synchronization
The prices of suppliers are constantly changing. A live price mechanism has been implemented at the payment stage to avoid discrepancies.

Instead of an outdated Joomla system with hourly support and unstable integrations, we got a modern Frapi travel platform that:

• It is built on its own three-level architecture
• combines hotels, cars, and transfers under one username
• gives the user a personal account, favorites, selections, and booking history.
• allows administrators to manage content and armor
• Ready to scale: Adding new vendors takes days, not weeks

This is not a copy of the old website with a new design. It’s a completely reimagined product ecosystem.