Options Considered

Treat the supplier as another catalogue source

Approach

Synchronise supplier data into the existing catalogue/search model and serve customer queries locally.

Strengths

• familiar website pattern;
• low runtime dependency on the external API;
• fast local search.

Limitations

• local data cannot guarantee current live availability or price;
• refresh cadence becomes part of customer accuracy;
• risks presenting a catalogue abstraction as authoritative when it is not.

This pattern could support discovery data, but it was not sufficient as the primary live-search architecture.

Direct browser-to-supplier integration

Approach

Let the customer-facing page call the external API directly.

Strengths

• shortest apparent request path;
• fewer internal components.

Limitations

• exposes supplier protocol concerns to the frontend;
• creates credential and trust-boundary problems;
• conflicts with controlled network-egress requirements;
• tightly couples Webflow to the external contract.

This was not an appropriate security or integration boundary.

Backend live-search integration

Approach

Introduce an internal backend boundary responsible for the supplier interaction and expose a stable website-facing contract.

Strengths

• keeps secrets and supplier-specific protocol server-side;
• isolates external API changes;
• supports response transformation and validation;
• provides a clear place for resilience, observability and policy;
• preserves Webflow as the presentation layer.

Trade-off

The website becomes dependent on an additional synchronous integration path.

Decision

Use a backend live-search integration and keep the website contract independent of the external supplier protocol.

The supplier remains authoritative for live holiday availability and price.