Scrape TUI package holiday prices, hotels and flights

Not a public one. The booking engine has internal endpoints under {languagePrefix}/api/ - hotel, offer, region, referenceData and booking, plus bookingVacancy, alternativeFlights, hotelAvailability, productcontent and hotelLookup - but they are not open to third parties. A plain HTTP request to /api/region or /api/offer comes back as HTTP 403 from Varnish with a page titled 'crawler/spider lock down', asking crawlers to contact TUI operations instead. There is no key to apply for and no feed to subscribe to. What we deliver is an extraction service built on the public pages, scoped and scheduled to what you actually need.

We work from publicly accessible pages, read and follow robots.txt, and stay out of anything behind a login. On tui.com robots.txt is permissive - User-agent: * with Allow: / - and a sitemap index is published, so the hotel pages themselves are open to crawlers. The booking engine endpoints are a separate matter: they are edge-restricted and explicitly ask crawlers to make contact, and we treat that as a boundary rather than an obstacle. Prices reach the public hotel page through a component rendered in the browser, and the rendered public page is what we work from. We keep request rates modest and collect factual product data, not editorial text or personal data. Legal advice for your own jurisdiction and use case has to come from your counsel.

Different infrastructure per country. tui.com, tui.at and tui.ch answer plain HTTP clients from a Varnish edge that identifies itself as plcache.edge. tui.co.uk, tui.nl, tui.be, tui.se, tui.dk, tui.no and tui.fi sit behind Akamai - the response header reads AkamaiGHost - and a non-browser client is refused with 403 Access Denied. tui.pl is a different stack again, a Next.js app on Vercel, and firstchoice.co.uk runs on CloudFront. We do not sell a way around bot management. We run a real browser environment, keep request rates polite, and tell you at the scoping stage which markets are cheap to cover and which are not.

GIATA IDs are industry-standard hotel identifiers, and tui.com carries one in every hotel URL, typically four to seven digits. The same ID is reused across the German-language tenants: hreflang on a tui.com hotel page points at tui.at and at tui.ch with the same number, and tui.ch adds a language prefix such as /de/ or /fr/ that the booking engine mirrors as its API prefix. Tenant is derived from the hostname as TUICOM, TUIAT or TUICH. Other markets share nothing. tui.nl uses a root-level slug with an eight-digit number, tui.pl uses destination-code hotel codes such as bcn10291 or tfs36003 that reappear in its image CDN paths, tui.co.uk uses slug-only .html paths, tui.se uses a pure slug hierarchy and tui.be prefixes the locale and appends ISO3 and IATA codes. Matching those markets is entity resolution against GIATA using name, address, coordinates and category, and we build that step into the pipeline.

Yes. Those are first-class search parameters - adults, boardType, destination, duration, searchScope, startDate and giataId among them, with the client switching to minified keys (a, bT, d, du, sS, sD) once a built URL passes 2083 characters. A scope such as All Inclusive, seven nights, Mallorca, departing DUS or HAJ, over the next six months is an ordinary request, and the matching offer deep link is /suchen/angebote/{Hotel-Name}/{giataId}/offer/. Flights run alongside packages: TUI publishes route pages such as /flug/duesseldorf-dus-mallorca-pmi/, fares load into a tui-flight-offer-list component carrying origin, destination and trip type, and the deep link is /flug/flugauswahl/ (flight selection) with origin, destination, dates and journeyType. The search bar declares market X3DE, X3 being the TUI fly carrier code. Output is CSV, JSON, XLSX or an API on your schedule; price depends on scope and refresh rate, so we quote after a short scoping call.