August 12, 20265 min read

Why the same fare or room shows a different price by location

By The Masklabs team

Search for the same flight twice from two different places and you can get two different prices. That's not a glitch. Airlines, hotel chains, rental car companies, and plenty of retailers quote prices based on where the request looks like it's coming from, and checking from one spot only tells you what one shopper sees.

How location shapes the price you're shown

Pricing engines use signal beyond the search itself: the requesting IP's city and country, the currency tied to that region, local promos and inventory, and sometimes device or carrier data. A hotel booking engine might show a lower nightly rate to a shopper who looks local, or push a package deal that's only live in one market. A rental car site might have different fleet availability by region, which changes the price even before any discount logic runs. None of this is visible in the price itself, so a single price pull can't tell you whether you're looking at the floor, the ceiling, or something in between.

Checking from a real location, not just your own

To see what a shopper in Denver sees, you need a connection that actually looks like Denver, on a real mobile carrier IP, not a datacenter range that booking sites are quick to flag or quietly serve default pricing to. Masklabs routes through exit addresses from real phones on carrier networks, and you pick the city with a suffix on your credential:

mlabs_a1f9c3_loc_den:<PASSWORD>@proxy.masklabs.io:8080

Swap _loc_den for any of the 46 supported cities and you get an exit in that market. Pull the same fare or room with _loc_lax, _loc_mia, and _loc_ord, and you're comparing what each city's shoppers are actually quoted, not guessing from one vantage point.

Sticky for the flow, rotating for the pulls

These two jobs need opposite session behavior, and Masklabs gives you both from the same credential.

Hold a sticky IP through a booking flow. Once you've found a fare or rate you want to trace through checkout, whether that's confirming the price survives to payment or watching how a dynamic price shifts as you add passengers or nights, you need one IP for the whole sequence. Sites that see the session's IP change mid-checkout will often bounce you or reset the cart. Add _sticky to keep the same exit for the flow:

mlabs_a1f9c3_loc_lax_sticky:<PASSWORD>@proxy.masklabs.io:8080

Rotate for independent price pulls. Checking the same search across many cities, or refreshing a price repeatedly to watch for change, doesn't need session continuity, each pull stands alone. Leave off _sticky and every request gets a fresh IP, which also keeps you from hammering one exit with repeated hits on the same target.

Comparison shopping and regional stock checks

The same setup covers more than fares. Retail sites run regional promos, region-locked stock, and price tests that only show up from inside a given market. If you're building a comparison tool or checking whether a listing is even available in a city before sending a customer there, pull it from that city's exit rather than assuming national pricing applies everywhere.

  • Run the same query across your target cities. Use one credential per project, like a price-check credential for sweeps and a staging one for test runs, and swap the _loc_<CITY> suffix while keeping everything else identical, so the only variable between pulls is location.
  • Keep pulls independent by default. Unless you're following one session through a flow that depends on IP continuity, rotating is the right default. It's simpler to reason about and it's what you're already on if you don't add _sticky.
  • Track usage by job. Give price-checking and flow-tracing separate credentials on the same plan. Each one gets its own usage line, drawing from the same GB pool, metered by the byte, so you can see how much of your data went to comparison sweeps versus checkout traces.

See the sessions and locations guide for the full suffix reference.

A note on responsible use

Checking regional pricing for research, comparison building, or your own purchases is routine. Respect the terms of the sites you check, follow applicable law, and don't use location checks to scrape data you don't have rights to or to interfere with a site's normal operation.

The bottom line

A price is a function of where the request looks like it's from, not a fixed number. Checking from a real mobile connection in each target city, rotating for independent pulls and sticky for anything that has to survive a multi-step flow, is how you see the market instead of one shopper's view of it. See pricing for plan details.