Chocodata
Country, region, and content language
How our API routes traffic to the right regional storefront and which languages each region actually serves.
Country, region, and content language
Three distinct concepts - don’t conflate them:
| Concept | What you control | Example |
|---|---|---|
| Region (TLD) | domain param | com → the US store, de → the German store |
| Content language | language param | en_US, de_DE, es_MX |
| Proxy egress country | automatic, not exposed | German store → DE residential IP |
Proxy egress is automatic
You don’t configure proxy egress. When you hit ?domain=de we automatically route through a residential IP in Germany. When you hit ?domain=co.jp we route through Japan. This matching reduces the target site’s anti-bot score and gives you the real desktop-locale HTML.
There was briefly a country parameter that let customers force a specific egress IP. We removed it - obvious mismatches (e.g. scraping a German store through a US IP) trigger anti-bot defenses disproportionately and add complexity without customer value.
Content language override
Some sites serve a region in multiple languages. Pass ?language=xx_YY to override:
GET /api/v1/{site}/product?query=PRODUCT_ID&domain=com&language=es_USThis maps to the site’s ?language=es_US URL parameter. The site then serves the Spanish US-region content: prices in USD, shipping from US warehouses, but titles, descriptions, and bullets translated to Spanish.
Supported languages per region (a worked example)
Multi-region sites follow the same domain + language model, though supported values vary by site. The table below uses one large multi-region marketplace’s storefronts as a concrete, empirically tested example of how regions map to default and alternate languages. Treat it as an illustration of the pattern, not a global list.
| Marketplace | Default | Other languages that work |
|---|---|---|
com (US) | en_US | de_DE, es_ES, es_US, zh_CN, pt_BR, ar_AE, en_GB |
co.uk (UK) | en_GB | de_DE, fr_FR, pl_PL, ro_RO, en_US |
de (Germany) | de_DE | en_GB, en_US, nl_NL, pl_PL, tr_TR, cs_CZ, fr_FR |
fr (France) | fr_FR | en_GB, de_DE, nl_NL, ar_AE |
it (Italy) | it_IT | en_GB, en_US, de_DE |
es (Spain) | es_ES | en_GB, en_US, pt_BR, pt_PT, ca_ES |
nl (Netherlands) | nl_NL | en_GB, de_DE |
pl (Poland) | pl_PL | (monolingual) |
se (Sweden) | sv_SE | en_GB |
ca (Canada) | en_CA | en_US, en_GB, fr_CA, fr_FR, zh_CN |
com.mx (Mexico) | es_MX | es_ES, en_US |
com.br (Brazil) | pt_BR | en_US |
com.au (Australia) | en_AU | en_US, en_GB, zh_CN |
co.jp (Japan) | ja_JP | en_US, en_GB, zh_CN, ko_KR |
sg (Singapore) | en_SG | en_US, en_GB, zh_CN |
in (India) | en_IN | en_US, hi_IN |
com.tr (Turkey) | tr_TR | en_US, en_GB |
ae (UAE) | en_AE | ar_AE, en_US |
sa (Saudi Arabia) | ar_SA | en_US, en_GB |
eg (Egypt) | ar_EG | en_US, en_GB |
If you pass a language that the region doesn’t support, the site silently falls back to the region’s default. No error from us.
What doesn’t change with language
The language parameter only affects presentation (titles, descriptions, bullets, UI text). It doesn’t affect:
- Price - always shown in the region’s native currency
- Availability / stock - physical availability is per-region, not per-language
- Shipping - ships from the region
- Reviews - a site may show reviews from multiple sources; the language flag doesn’t filter them
If you need Spanish-language product data from the Mexican store, use domain=com.mx (which defaults to es_MX). If you want Spanish-language data from the US store (available to US-Spanish speakers), use domain=com&language=es_US.