Jet2Holidays API Integration

Executive Overview

The holiday integration introduced a different architectural pattern from catalogue-backed travel products. Availability and price depend on live customer search criteria, so the website cannot rely solely on a periodically synchronised local catalogue.

The challenge was to introduce live external availability without pushing authentication, protocol handling or supplier-specific integration concerns into the frontend.

My contribution focused on the solution and integration architecture: clarifying the live-search model, defining the system boundary, separating search from booking scope, establishing the backend integration responsibility, shaping the information flow and identifying the operational constraints that materially affect the design.

The resulting architecture places a controlled backend integration layer between Webflow and the external holiday API. Webflow owns the search experience, the integration layer owns authentication and transformation, and the external provider remains authoritative for live availability and price.

Why the problem mattered

Catalogue-backed search and live availability search have different architectural characteristics.

A locally indexed catalogue can answer many customer queries without contacting the source system. Live holiday search, by contrast, depends on criteria such as departure airport, destination, date, duration and occupancy at the time of the request.

That affects:

• latency and dependency management;
• caching strategy;
• error behaviour;
• request validation;
• information freshness;
• network and authentication boundaries;
• how the customer journey hands off into booking.

Architectural responsibility

The work required decisions across several concerns:

• where the external integration boundary should sit;
• which search inputs are required before calling the supplier;
• how authentication and supplier-specific protocol handling should be isolated;
• how Webflow should receive a frontend-friendly result model;
• how live availability differs from catalogue discovery;
• how the search journey should remain separate from booking and payment;
• how fixed-egress and operational constraints affect deployment;
• how failures and degraded external availability should be handled.

Architecture at a glance

flowchart LR
    U[Customer]
    W[Webflow experience]
    I[Backend integration layer]
    N[Controlled network boundary]
    J[Holiday availability API]

    U -->|search criteria| W
    W -->|validated search request| I
    I --> N
    N -->|authenticated live request| J
    J -->|availability + price| N
    N --> I
    I -->|normalised result model| W
    W -->|results| U

The backend integration layer shields the customer-facing application from supplier-specific authentication, transport and response formats.

Case study navigation

The supporting pages follow the architectural reasoning from context to outcome:

• Context & Drivers — business need, stakeholders, scope and constraints.
• Current-State Architecture — catalogue-style assumptions and why live search changes them.
• Options Considered — alternative integration patterns and trade-offs.
• Target Architecture — selected responsibilities and trust boundaries.
• Request & Information Flow — live search from customer criteria to normalised results.
• Architecture Decisions — key integration choices and consequences.
• Resilience, Security & Operations — external dependency, secrets, failure and support concerns.
• Transition Approach — how live search can be introduced alongside existing journeys.
• Validation & Outcomes — evidence and architectural value.

Outcome

The design establishes a clear separation between the customer experience and the external supplier integration.

Webflow does not need to understand supplier authentication or protocol details, while the backend can enforce a stable internal contract and isolate changes in the external API.

The architecture also keeps the initial capability deliberately focused on search and browse, allowing booking to remain an external responsibility rather than expanding the system boundary unnecessarily.