Context & Drivers

Business context

The website platform already supported travel products that could be treated largely as catalogue data: retrieve or synchronise records, index them and let customers browse a local representation.

The holiday supplier integration introduced a different architectural pattern because availability and price are determined from a live search request.

That changes where responsibility belongs and how the customer journey should interact with the source system.

Stakeholders and concerns

Customers need timely, understandable holiday results based on their current search criteria.

Marketing and digital teams need the search experience to fit the existing website journey and presentation model.

Frontend development needs a stable, frontend-friendly contract rather than supplier-specific protocol details.

Integration/platform teams need to protect credentials, satisfy network constraints and isolate external API changes from the website.

Operations need clear failure behaviour and support boundaries for an external live dependency.

Scope and boundaries

In scope:

• live holiday search;
• availability and price retrieval;
• normalisation of supplier responses;
• Webflow-oriented presentation;
• backend authentication and protocol handling;
• onward customer handoff where appropriate.

Out of scope:

• owning payment;
• creating an internal booking engine;
• customer booking-session management;
• replacing the supplier's booking responsibility.

Drivers and constraints

The main architectural forces were:

• live external availability;
• external-system latency and availability;
• supplier authentication;
• XML/SOAP integration;
• controlled network egress;
• Webflow compatibility;
• a deliberately bounded search/browse scope.

These concerns led to a backend integration boundary rather than direct browser-to-supplier communication.