Skyscanner is a flight metasearch, and every search it runs is stamped with three things before a single fare comes back: a market, a locale and a currency. Its own partner API makes all three required fields. That stamp is why "change the country on Skyscanner" is one of the oldest fare tricks on the internet, and it is why proxies for Skyscanner are about more than getting unblocked. They decide which market's fares you are reading at all.
We run a proxy network, and Skyscanner traffic comes to us from fare trackers, deal sites and travel-data teams checking coverage and price by country. This is the practical page for that job: the partner API and who gets it, how the market setting works, what PerimeterX does to scrapers, which proxy type survives, and how to size it. The sector background is in travel fare aggregation; the closest siblings are proxies for Google Flights and proxies for Kayak.
What proxies are best for Skyscanner?
Rotating residential proxies pinned to the market you want, driven through a real browser, with one sticky session per search and a fresh IP for the next. Skyscanner's bot management is HUMAN's PerimeterX, which fingerprints the client and answers scripts with an immediate 403, so the IP has to be a home connection and the client has to look like a browser. Datacenter proxies are blocked on arrival. Mobile exits are only relevant to tools that talk to the app's endpoints, and ISP only for a small, slow monitor on a few addresses.
The partner API, and why most people are on the public site
Skyscanner has a real API, and it is the sanctioned route if you can get it. The developer documentation lists Flights Live Prices and Indicative Prices, the same pair for Hotels and Car Hire, a Culture API for supported markets, locales and currencies, a Geo API, and an affiliate link API for deep links (Skyscanner API documentation). It is provided to partners through a partner portal with an account manager, and Skyscanner's partner site describes selection on a case-by-case basis with a business review, a commercial agreement and production credentials that take weeks, with revenue share on bookings as the commercial model (Skyscanner Partners, Travel API).
Two details in the Flights Live Prices documentation explain how the public site behaves too. The search is a two-step flow: a create call starts it and returns an incomplete cached subset for a quicker time to first result, then poll calls retrieve the complete list, because some supply partners take longer to return inventory results, and often the best itineraries come from the partners that take longer (Flights Live Prices overview). And every search requires market ("Market where search is coming from. E.g.: UK"), locale and currency. The public page does the same create-then-poll dance in your browser, which is why results fill in over ten to thirty seconds, and why a scraper that reads the page once and leaves gets the cheap early subset and misses the fares that arrive late.
Create search
market, locale, currency
First results
cached subset, fast
Poll
partners answer over seconds
Complete list
late partners, often the best fares
If you cannot get a partnership, you are reading the public site, and Skyscanner's terms prohibit it. Tools marketed as Skyscanner scraper alternatives violate those terms (ScrapingBee, top flight APIs). Proxies do not change that; they change whether the read succeeds.
The market setting is the price
The country selector at the bottom of every Skyscanner page sets the market, and the market is what the airline sees as the point of sale. Airlines file some fares by market, discounting in their home market or pricing a route differently for sale in one country than another, so the same flight can come back cheaper when searched as a resident of the airline's home country. That is the mechanism behind a well-shared set of instructions for cycling through Skyscanner's countries until the cheapest point of sale appears (GitHub gist, Skyscanner point of sale).
It is real, and it is also the exception. When EXPERTE tested four long routes (London to New York, Munich to Melbourne, Berlin to Stockholm, Los Angeles to Tokyo) from Germany, the United States, Portugal and Japan on Skyscanner, clearing cache and cookies between sessions, every price came back identical (EXPERTE). So the collection rule is not "prices always differ by market." It is: to know a market's price you have to search as that market, and only then can you say whether it differs.
For a fare tracker this decides the architecture. Reading one route from five markets is five searches, not one search with a currency switch, and each must be created and polled in that market's context. The selector sets the context; the proxy places the request in the country the context claims. A search stamped market=BR from a Frankfurt datacenter is a mixed signal to a system that checks both.
How Skyscanner blocks you
Skyscanner's public site sits behind HUMAN's PerimeterX. The signature is a 403 with the message "Access banned. CAPTCHA challenge encountered", and it arrives instantly. A developer of an open-source Skyscanner client reported exactly that: a persistent 403 despite IP rotation, new networks and mobile data, while a browser from the same address loaded the site normally, and concluded the client's fingerprint or headers were flagged by Skyscanner's PerimeterX protections (GitHub, irrisolto/skyscanner issue #2). The header names in that project (X-Px-Mobile-Sdk-Version) show the same protection guards the app's endpoints.
That report is the whole lesson in one line: the block happened on fresh IPs. PerimeterX scores the TLS handshake, the header set, the JavaScript environment and the timing of a session before it weighs the address, and returns a 403 or injects a press-and-hold challenge when the score is low. A clean residential IP under a Python default client still fails. A real browser on a datacenter IP fails on the IP. Both have to be right.
Which proxy type fits: residential, datacenter, ISP, or mobile
Datacenter proxies fail the reputation check before anything else runs. Keep them for reading a saved page during parser development.
Rotating residential proxies are home connections pulled from a pool, one per search session, pinned to the market the search claims. They clear the address half of the PerimeterX score and place the search in the right point of sale. Pair them with a real browser and they are the setup that reads Skyscanner on a schedule (background in what is a residential proxy).
ISP proxies hold one static residential address. Skyscanner needs no account for a search, so ISP is only the right call for a small monitor that runs a few searches a day from a few addresses it wants to keep clean.
Mobile proxies are carrier addresses shared by many phones. They matter for tools that call the app's endpoints with the mobile SDK headers, because the traffic then matches its claimed origin, and for the runs nothing else survives. Most trackers never need them.
| Skyscanner job | Proxy type | Why |
|---|---|---|
| Fare tracking across routes and dates | Rotating residential, market-pinned | One home IP per search session; the pool spreads the schedule |
| Per-market price reads | Rotating residential in that market | The market setting and the exit country must agree |
| Small daily monitor, a few routes | ISP (static residential) | A few clean addresses, kept slow |
| App-endpoint tools | Mobile | Traffic matches the mobile SDK it claims to be |
| Parser development | Datacenter or free list | Saved pages, nothing at stake |
Free versus paid for Skyscanner
Free proxies are datacenter addresses shared by strangers, which is the profile PerimeterX rejects first, so the expectation is a 403 before the page loads. We tested a batch of free proxies from our own list against Skyscanner and wrote down the result in free proxies for Skyscanner. For a manual look at another market's prices, the country selector does the job without any proxy at all. When the job is a schedule, paid residential behind a real browser is the floor, and ours starts at $0.44/GB pay-as-you-go with no KYC, so a first run costs cents. Our free proxy list and proxy checker are there for testing your own setup first.
Setting it up
Drive a browser, not a request library. Playwright or Puppeteer behind a residential exit is the minimum against PerimeterX; our guides for Playwright and Puppeteer cover the wiring. Leave the browser's own TLS and header order alone, keep a normal viewport, and do not strip the cookies PerimeterX sets, because a session that arrives with no history every time is a session that never passes.
Set the market before you search. Use the selector, or the market, locale and currency parameters where the page accepts them, and make the exit country match. Searching as UK from a UK residential IP in en-GB with GBP is one consistent visitor; mixing them is three.
Wait for the poll to finish. Results arrive in phases. Read the list only after the loading indicator settles, or you will store the early cached subset and miss the fares that arrive from slower partners, which the API documentation says are often the best ones.
Hold one IP per search, then rotate. A sticky session of about a minute covers create and poll; the next search should come from a fresh residential address so no single one builds a monitor's history. The split between sticky and rotating is explained in rotating vs static residential proxies.
How many IPs, and how fast
The unit is the search session, and it is heavier than a page view because it lasts as long as the poll does.
Sizing (rotating residential, one refresh cycle):
searches/cycle = routes x dates x markets
= 50 routes x 30 dates x 4 markets = 6,000 searches
session length = ~10 to 30 seconds (create + poll)
page weight = a browser session per search; block images and fonts
One sticky IP per search, a fresh IP for the next, gentle pacing.
The pool spreads 6,000 sessions; the bandwidth is the bill.
Refresh near-term dates daily and far dates weekly, and the count drops by more than half. Our pricing is per gigabyte with no expiry, so a seasonal tracker pays only for the months it runs.
Staying unblocked on Skyscanner
- Real browser, home IP, both at once. PerimeterX scores the client and the address; fixing one leaves the other failing.
- Make the market, locale, currency and exit country agree. A consistent visitor is the whole game on a point-of-sale site.
- Keep the session cookies for the session, then drop them with the IP. History within a search, none across searches.
- Let the poll finish. Reading early is not a block, but it is wrong data, and it wastes the session you paid for.
- Pace the schedule. Jitter the gaps, spread markets across the day, and never run on the clock. The general checklist is in avoiding IP bans while scraping.
- Treat the first 403 as a signal, not a retry. A "CAPTCHA challenge encountered" from one session means the fingerprint is off; retrying the same client on a new IP is what the GitHub report shows failing.
The limits worth knowing
Proxies put a Skyscanner search in the right country on the right kind of connection, and they spread a tracker across enough addresses that none of them looks like one. They do not beat PerimeterX on their own, because half of its score is about the client, and they do not create a partnership with Skyscanner or change its terms of service. If you qualify for the Travel API, use it: it gives you the market, locale and currency controls directly and removes the whole problem.
For a manual look, the country selector is free and enough. For a tracker, rotating residential at $0.44/GB pay-as-you-go behind a real browser, one sticky session per search, pinned to the market you are reading, is what keeps Skyscanner readable.
Sources
- Skyscanner, API developer documentation, introduction, and Flights Live Prices overview, on the partner APIs, required market, locale and currency fields, and create-then-poll.
- Skyscanner Partners, Travel API, on partner selection and the commercial model.
- ScrapingBee, top flight APIs for travel apps, on Skyscanner's terms and scraper tools.
- GitHub, irrisolto/skyscanner issue #2, the persistent 403 on fresh IPs and the PerimeterX headers.
- GitHub gist, Skyscanner point of sale, on cycling the country selector.
- EXPERTE, cheaper flights with a VPN: does it work?, the four-route, four-country Skyscanner test.