Apple storefront IDs: what X-Apple-Store-Front is and the numbers you need

An Apple storefront ID is a five- or six-digit number identifying one country's App Store. The United States is 143441. Some of Apple's endpoints will not accept a two-letter country code and want this number in an HTTP header instead:

X-Apple-Store-Front: 143441-1,29

Here are the ones worth having to hand:

Country	ISO code	Storefront ID
Australia	au	143460
Brazil	br	143503
Canada	ca	143455
France	fr	143442
Germany	de	143443
India	in	143467
Italy	it	143450
Japan	jp	143462
Mexico	mx	143468
Netherlands	nl	143452
South Korea	kr	143466
Spain	es	143454
Sweden	se	143456
United Kingdom	gb	143444
United States	us	143441

Fifteen territories, which is fifteen out of roughly 175. The full list is not in this article and probably should not be in any article, for reasons covered below.

Note gb, not uk. Apple uses the ISO code for the United Kingdom, and uk is rejected.

What the header is actually for

Most of what you need from Apple is available through the public iTunes Search API, which takes a plain two-letter country code:

https://itunes.apple.com/search?term=habit+tracker&country=de&entity=software&limit=200
https://itunes.apple.com/lookup?bundleId=com.example.app&entity=software

No storefront ID, no header, no credentials. If you are doing keyword rank checks or pulling a competitor's public listing, this is the endpoint and you can stop reading.

The storefront ID matters for the older, undocumented endpoints that predate that API and never got a country parameter. The search suggestions endpoint is the one most people end up wanting:

GET https://search.itunes.apple.com/WebObjects/MZSearchHints.woa/wa/hints
      ?clientApplication=Software&term=habit
Header: X-Apple-Store-Front: 143443-1,29

That returns the autocomplete terms Apple offers a real shopper typing "habit" in the German App Store. It is a genuinely useful signal, and there is no supported alternative, so the header is the price of entry.

The WebObjects in the path is a clue to its age. These are not App Store Connect API endpoints, they are the endpoints iTunes itself used, and they behave accordingly.

What -1,29 means

Honestly: nobody outside Apple knows for certain, and Apple has never documented it.

The suffix appears to encode a language index and a client or platform version, so 143443-1,29 reads as the German storefront, language variant 1, client generation 29. That is the community reading, arrived at by observation, not a published specification.

What is verifiable is that the suffix is required. Sending a bare 143443 gets you a different response shape or nothing at all, and the working value is the one that is currently working. Copy it, do not derive it.

Why you should not trust a big list of these

You can find tables of 175 storefront IDs online. They are mostly correct, mostly scraped from each other, and occasionally wrong in ways you will not notice.

Three specific hazards:

Territories change. Apple has opened and closed storefronts, and has changed regional groupings. An ID that worked in 2017 may map to a territory that has since been reorganised.

The endpoints are unsupported. Nothing about MZSearchHints.woa is covered by an Apple API contract. It can change response shape, start requiring different headers, rate-limit differently by region, or go away. Code that depends on it needs to fail gracefully, not retry harder.

A wrong storefront returns plausible data. This is the real problem. Send the Brazilian ID when you meant Mexico and you get valid suggestions in Portuguese, which look fine until someone notices the Mexican rank tracking has been Brazilian for a month. Unlike a bad locale code, a wrong-but-valid storefront ID does not error.

So the useful discipline is to carry only the storefronts you actually track, verify each one once against a result you can recognise, and add new ones deliberately. Fifteen verified IDs beat 175 copied ones.

Storefronts, territories and locales are three different things

Worth separating, because all three get called "region":

Concept	Vocabulary	Controls
Locale	en-US, ja, de-DE	The language of your listing text
Territory	USA, JPN, DEU in App Store Connect; us, jp, de in the search API	Availability and price
Storefront	143441, 143462, 143443	Which country's store an undocumented endpoint answers as

They do not line up neatly. App Store Connect's territory identifiers are three-letter codes, the iTunes Search API wants two letters, and the hints endpoint wants a number. The same country therefore has three different identifiers depending on which Apple surface you are talking to, and none of them is derivable from the others.

Google Play, for what it is worth, uses two-letter country codes throughout and has no equivalent numeric concept. It also exposes no search API at all, so the whole storefront question does not arise there. The trade is real: Apple gives you undocumented endpoints that work, Google gives you documented endpoints that do not cover search.

If you are building rank tracking on this

Two things worth knowing before you start.

The search API allows roughly 20 requests a minute before it starts refusing you, so a sweep across many keywords and countries needs a delay between calls rather than concurrency. Politeness here is not etiquette, it is the difference between data and a 403.

And when the hints endpoint is unavailable, record that it was unavailable. A demand signal that silently becomes zero when a request fails is worse than no signal, because zero looks like an answer.

AppSubmit uses exactly the fifteen storefronts in the table above for its Apple demand probes, and skips a check rather than reporting a fabricated one when the endpoint refuses. The IDs are the whole dependency, and the table is all of it.