Regional availability
How country targeting actually reaches a provider, how to confirm a request was routed through the region you asked for, and why a regional response and the model's phrasing are two separate things.
Overview
Every request you submit is dispatched through infrastructure located inside the country you name with the country parameter. Which countries a given provider supports — and how finely you can target within them — is not fixed across the platform, so treat the live list as authoritative. Query GET /v1/countries to retrieve every supported region, and narrow it to one provider by adding ?model=<provider>. This page covers what that endpoint reference does not: proving the region was applied, and how prompt language relates to geographic routing.
Language is separate from routing
The country parameter decides where a request originates. It does not instruct the model to reply in any particular language. Most providers pick up the response language from the wording of your prompt, so a request routed through Mexico still answers in English if the prompt was written in English. When you need a localized answer, write the prompt in the target region's language rather than relying on country to switch it for you.
Prompts that mix an English question with a non-English region usually complete, but the localization can be uneven. Aligning the prompt language with the targeted country gives the most consistent results.
Confirming the region was applied
A frequent question is why a response mentions one country when a different one was targeted — and whether that means routing failed. In nearly all cases the routing worked, and what you are reading is model behavior rather than a proxy fault. Four signals help you tell them apart:
| Signal | What it tells you |
|---|---|
result.sources | The most reliable evidence. Citations on the targeted country's domains (.de, .fr, .com.br) confirm the request was served from that region. Region-appropriate sources paired with US-leaning prose is model bias, not a routing error. |
| Rendered HTML | Set include.html to true and inspect the returned page. Its interface language, currency, and regional layout reflect the location the request actually came from. |
| Training leakage | Models weighted toward US English content sometimes default to US references regardless of origin. The region was applied; the model simply disregarded it. |
| Prompt intent | A prompt naming a specific place (for example, a city) returns that place from any region. The country value shapes what the retrieval layer sees, not what the prompt explicitly requests. |
If sources, HTML chrome, and response language all point to the wrong region at once, that is worth reporting. Include the taskId and the country you submitted when you reach out.
Response example
{
"object": "list",
"model": "chatgpt",
"countries": [
{ "code": "US", "name": "United States", "granularity": "city" },
{ "code": "DE", "name": "Germany", "granularity": "country" },
{ "code": "BR", "name": "Brazil", "granularity": "country" },
{ "code": "JP", "name": "Japan", "granularity": "country" }
]
}Notes
Provider coverage shifts over time as upstream products roll out regional changes, so a country that worked previously can start returning 400 errors. Re-fetch /v1/countries?model=<provider> before treating it as a regression — the returned list is the source of truth. If the region is still listed but requests keep failing, contact [email protected] with the taskId.