The Avvail API uses explicit locale tags to determine the language of transactional communications (confirmation, reminder, and cancellation emails) sent to guests. Locale is never inferred from country, market, or any other geographic field.
How Locale Resolution Works
When creating a reservation via POST /v2/reservations, you may include an optional locale field. If omitted, the server falls back to the entity's default_locale. If the entity has no default_locale configured, en-US is used.
reservation.locale → entity.default_locale → en-US
Once set on a reservation, the locale is immutable and cannot be changed via PATCH /v2/reservations/{id}.
Configuring Entity Defaults
Each entity can have a default_locale set via POST /v2/entities or PATCH /v2/entities/{id}. This is useful when an entity (distribution channel) primarily serves a single-language market.
curl -X PATCH https://api.avvail.com/v2/entities/7f3c2b1a-8e4d-4f9c-a6b2-3d5e1a7c9f2b \
-H "Authorization: Bearer YOUR_ACCESS_TOKEN" \
-H "Content-Type: application/json" \
-d '{"default_locale": "fr-FR"}'
Setting Locale on a Reservation
Pass locale in the reservation creation request to override the entity default:
curl -X POST https://api.avvail.com/v2/reservations \
-H "Authorization: Bearer YOUR_ACCESS_TOKEN" \
-H "Content-Type: application/json" \
-d '{
"option_id": "opt_abc123xyz",
"locale": "ar-001",
"guest": {
"first_name": "Nadia",
"last_name": "Hassan",
"email": "nadia.hassan@example.com",
"mobile_number": "+971555555555"
}
}'
The resolved locale is returned in the reservation response as a read-only field.
Supported Locale Codes
All values are BCP 47-style tags. The locale and default_locale fields accept only the values listed below.
| Code | Language |
|---|---|
ar-001 |
Arabic (Modern Standard Arabic) |
cs-CZ |
Czech (Czech Republic) |
da-DK |
Danish (Denmark) |
de-DE |
German (Germany) |
el-GR |
Greek (Greece) |
en-GB |
English (United Kingdom) |
en-US |
English (United States) |
es-419 |
Spanish (Latin America) |
es-ES |
Spanish (Spain) |
fi-FI |
Finnish (Finland) |
fr-CA |
French (Canada) |
fr-FR |
French (France) |
hr-HR |
Croatian (Croatia) |
it-IT |
Italian (Italy) |
ja-JP |
Japanese (Japan) |
ko-KR |
Korean (Korea) |
ms-MY |
Malay (Malaysia) |
nb-NO |
Norwegian Bokmål (Norway) |
nl-NL |
Dutch (Netherlands) |
pt-PT |
Portuguese (Portugal) |
sv-SE |
Swedish (Sweden) |
tr-TR |
Turkish (Turkey) |
zh-Hans-CN |
Chinese (Simplified, China) |
zh-Hant-HK |
Chinese (Traditional, Hong Kong) |
zh-Hant-TW |
Chinese (Traditional, Taiwan) |
Providing an unsupported value returns 400 Bad Request with a validation error.
Key Points
localecontrols transactional email language only — it does not affect API response content or error messageslocaleis separate fromcountryandmarket— a guest in France may receive emails in English, and vice versalocaleis immutable on a reservation once created- Entities without an explicit
default_localedefault toen-US
What Gets Localized
When a reservation is persisted with a non-en-US locale, the following surfaces render in the guest's language:
- Email body copy — all transactional copy in guest-facing emails sent for the reservation.
- Email subject line — e.g. "Votre réservation au Le Bistro est confirmée !" for
fr-FR. - Date and time formatting inside the body — month and day-of-week names, component order, and 12- vs 24-hour clock all follow the locale's conventions.