The case for a worldwide product database
Most product APIs are quietly regional. They claim "global" coverage and then return mostly U.S. retailers, mostly in English, mostly priced in dollars. The moment your users sit outside that bubble — buying in Mexico, browsing in French, shipping from Germany — the cracks show.
A real worldwide product API is not a U.S. catalog with a translation layer bolted on. It is product data that was retrieved, indexed, and structured with the assumption that every product has multiple regions, multiple currencies, and multiple languages, none of which are second-class.
This article walks through what that actually requires under the hood, what trade-offs you have to make, and how to query a global product database from your application so that a user in Tokyo, São Paulo, or Lyon gets a result that makes sense for them.
What "global" actually means
When teams ask for a global product database, they usually mean some combination of:
- Worldwide brand coverage — not just U.S./EU brands, but brands that matter regionally (Xiaomi in Asia, Vivara in Brazil, Decathlon in France, Flipkart's house brands in India).
- Multi-region availability data — knowing a product exists is not the same as knowing it's available where the user lives.
- Multi-currency pricing — both display currency and the underlying market currency.
- Multi-language metadata — names, descriptions, and specs in the user's language, not auto-translated mush.
- Region-appropriate units — kilograms in Europe, pounds in the U.S., centimeters vs inches, Celsius vs Fahrenheit.
A serious international product API treats every one of these as a first-class concern. Most vendors treat the first one and call it a day.
The three coverage problems
Real global coverage is a stacked problem. You're not just translating — you're solving three things in parallel.
1. Catalog breadth
The product has to exist in your dataset in the first place. Regional brands are routinely missed by catalogs that index from U.S. retailer sitemaps. The fix isn't a single bigger crawl — it's region-specific retrieval, plus the ability to fetch on demand when a query mentions something the index hasn't seen.
2. Locale-correct metadata
A French user typing "chaussures de running légères pour marathon" should not get back English product names. A localized product data layer means the canonical name, description, and specs are returned in the user's language — either because the source was indexed in that language, or because translation happens upstream of the API response, not in your frontend.
3. Region-correct values
Price, availability, units, voltage, plug type, regulatory labels — these vary by region for the same physical product. A vacuum cleaner sold as 230V 50Hz in Europe is the same model number as a 120V 60Hz version in the U.S., but the spec sheets are not interchangeable.
How to query with region in mind
A multi-region product data API typically exposes a few axes you can vary per request:
- Country — narrows availability, currency, and retailer scope
- Language — controls the language of names, descriptions, and specs
- Currency — overrides display currency independently of country (useful for travel and B2B)
A request that gets all three right looks like:
curl "https://productapi.dev/api?search=lightweight+marathon+running+shoes&country=FR&lang=fr¤cy=EUR" \ -H "X-API-Key: your-api-key"
The response should give you products that are actually available in France, with French names and descriptions, with prices in euros. If any of those three are missing or wrong, you have a coverage bug, not a translation problem.
Designing your app for locale
Even with a strong worldwide product API, your application has to be designed to consume it correctly. A surprising number of teams pass a hard-coded country=US and then wonder why their European users complain about availability.
A few patterns that work well:
Detect locale once, pass it everywhere
When the user signs in (or on the first request, via IP / Accept-Language), determine their country and preferred language. Store them. Pass them to every product query. Treat them as required fields in your internal API, not optional ones.
Don't conflate country and language
A user in Belgium might want results in French or Dutch. A user in Switzerland might want German, French, or Italian. A user in Canada might want English or French. Country alone doesn't determine language — let users override.
Cache by locale key
Caching product responses without including locale in the cache key is one of the most common bugs in this space. product:wh-1000xm5 should be product:wh-1000xm5:FR:fr:EUR. Same product, different locale, different response, different cache entry.
Handle currency formatting on the client
The API gives you a number and a currency code. Formatting (€379, ¥45,000, R$ 1.890,00) is a presentation concern. Use Intl.NumberFormat or your framework's i18n layer — don't expect the API to pre-format strings, and don't try to format them yourself with a switch statement.
Common gotchas
A few things that bite teams the first time they ship globally:
Auto-translated descriptions
If your provider's "French" descriptions are machine-translated English, it will be obvious to native speakers and embarrassing on premium catalog pages. Ask vendors specifically whether localized descriptions are sourced or translated.
Phantom availability
A product can show up in a regional search but actually not ship there. This is especially common with marketplaces. Cross-check availability against ship-to data when the stakes are real (checkout, recommendations from a basket).
Tax-inclusive vs tax-exclusive pricing
The U.S. quotes pre-tax, most of the EU quotes including VAT, Japan can be either. If you're showing a price next to a product, get the convention right for the user's locale — and label it.
Regulatory and safety labels
Some product categories require specific labels per region (EU energy ratings, CE marking, FCC IDs). Generic global APIs typically don't carry these. If you're in a regulated category, treat regulatory data as a separate concern.
Building for international users from day one
If you're starting a project that will eventually need to serve users globally, a few early choices save enormous pain later.
- Make locale a first-class request parameter in your internal API, even if it's hard-coded to one value at first.
- Store all prices with an explicit currency, never just a number.
- Use ISO codes —
FR,fr,EUR— everywhere. Don't invent your own enums. - Test with non-Latin queries early. Japanese, Arabic, Korean queries are where rendering and tokenization bugs surface.
- Plan for fallback chains. If localized data isn't available for a region, fall back to a neighboring locale (Belgian French → French) rather than English.
A worked example: marketplaces with global sellers
Imagine you're building a marketplace where buyers from anywhere can search and sellers from anywhere can list. The product enrichment problem becomes a locale-matching problem:
- A French buyer searches
chaussures running→ API returns localized French products → seller's listing shows in French. - A Brazilian buyer searches the same product (in Portuguese) → API returns localized Brazilian products → seller's listing renders in Portuguese, prices in BRL, with VAT shown as expected locally.
The seller did not have to maintain twelve listings in twelve languages. The API did the work, and the listing rendered correctly per buyer.
Try it
Try a query in your own region:
curl "https://productapi.dev/api?search=ordinateur+portable+15+pouces&country=FR&lang=fr¤cy=EUR" \ -H "X-API-Key: your-api-key"
Or try the same search localized to a different market and see how the results change. Get an API key — 20 free credits, no card required.
TL;DR
- A real worldwide product API is not a U.S. catalog with a translate-button wrapper.
- "Global" really means three problems at once: catalog breadth, localized metadata, region-correct values.
- Pass country, language, and currency explicitly on every request. Don't conflate them.
- Cache, store prices, and design your internal API with locale as a first-class field.
- Build for multi-region product data from day one — retrofitting later is painful.