# App storefronts by country: US, Japan, Germany 2026-08-27 > The same app query on US, Japan, and Germany catalogs. A storefront here is a country’s store, not Shopify. - Index: https://fetcher.sh/blog.md - This page (HTML): https://fetcher.sh/blog/app-storefronts-by-country-us-japan-germany ![A smartphone standing on a desk showing an app](https://images.unsplash.com/photo-1601972599720-36938d4ecd31?auto=format&fit=crop&w=1600&q=80) Photo by Tyler Lastovich on [Unsplash](https://unsplash.com/?utm_source=fetcher_sh&utm_medium=referral). A storefront, here, is which country’s app catalog you read — not a Shopify checkout, not shipping, not a physical shop window. Apple’s App Store and Google Play both take a country parameter. Titles, availability, and reviews can differ. ASO work often needs more than the US store. `country=us|jp|de` on the Apple App Store; country on Google Play. The hosts already feature these examples: US habit tracker, Japanese camera, paid photo editor on the German Play store. Those are not cute flags. They are different catalogs. [Play](/blog/google-play-apps-reviews-permissions-data-safety) and [Apple](/blog/apple-app-store-apps-bundles-similar) access notes, plus [ASO](/blog/aso-competitor-tracking-without-sensor-tower), sit underneath. This note is the parameter. ## One query, three catalogs Apple: `country` on app search. Play: `country` on app search. `curl -H 'Authorization: Bearer bby_live_…' 'https://appstore.fetcher.sh/api/apps?term=camera&country=jp'` An app id from the US storefront is not automatically valid as a Japan lookup — search that storefront, then fetch similar and reviews there. Shopify checkouts are unrelated. Play’s country parameter lives on googleplay.fetcher.sh, with optional `price` and `lang`. Screenshots, subtitle, and “in-app purchases” copy are localized objects. If you only ever fetch `us`, you have never seen the listing the Japanese user sees. Reviews are storefront-local too. A US 4.8 and a JP 3.9 is a real pattern, not a bug in the API. Availability differs. An app can be missing on a storefront, renamed, or sitting behind a different developer listing. Search, then store the id *for that country*. Do not assume the US id is a global primary key. ## Why US-default research lies English-language teams default to `us` because it is the featured example and because they can read the results. That is fine for a US-only product. It is a silent error for a product that ships in Japan or Germany. Similar-apps graphs change. Competitors that do not exist in the US show up. Keywords that are obvious in English are not the query people type in Japanese. You cannot fix that with a translation layer on US JSON. You have to search `jp`. Germany is the useful third because it is a large Play market with a different privacy conversation. Data-safety reading on `country=de` plus US is more honest than US alone if you sell into the EU. Still not legal advice. Still the public listing. ## A case: the same camera app, three storefronts A localization lead searches `camera` in `us`, `jp`, and `de`. Titles change. Availability changes. Similar-apps graphs change. They store three ids if needed and they do not assume the US listing is the source of truth. They pull reviews on each. The Japanese reviews argue about a local social network the US listing never mentions. The German reviews argue about a payment method. The US reviews argue about RAW files. One product, three conversations. A single storefront feed would have called two of them invisible. [ASO](/blog/aso-competitor-tracking-without-sensor-tower) then uses those ids for similar-apps diffs per country, not one global graph. ## A case: a paid app that is free in one catalog Play search with `price=paid` and `country=de` was in the featured examples for a reason. Pricing is a storefront fact. They find a photo editor that is paid in Germany and sits in a different similar-apps neighborhood than the US free tier of a cousin app. They do not “convert currency” in a spreadsheet and call it the same SKU. They record price *and* country. Shopify is still not involved. Connect and Play Console are how you *change* the price. This host is how you *see* it. Language on Play (`lang`) is not the same knob as country. A German storefront can still return English listing text depending on how you ask. If the question is “what does a user in Japan see,” set `country=jp` on Apple and country plus lang on Play, then look at the JSON instead of translating the US subtitle in a doc. Reviews must be fetched per storefront too. A US 4.8 with “works on my iPhone” is not a substitute for JP reviews about a local payment method. ASO people who skip this ship a US listing worldwide and call it localization. A localization Monday: the same `term` on `us`, `jp`, `de`, store titles and ids, fetch similar and reviews per country. Play gets the same countries plus `lang` when the listing language is the question. Shopify remains a different word. Maps `countryCode` remains a different knob. If they only ship in the US, they can ignore this note. If they say “we ship worldwide” and only fetch `us`, they are lying to themselves. ## Not a shop A storefront here is a country’s app catalog. Not Connect. Not geocoding. Not checkout. Not a pop-up shop. Docs on both hosts. 402 or a prepaid key. If you needed Maps country codes for a cafe, you are in the wrong article — [place search](/blog/place-search-text-query-vs-coordinates) is a different `countryCode`.