Skip to main content
This page is the live source of truth for the language codes accepted by the Didit API. It is referenced from the OpenAPI specs for both the session-level language field and the contact_details.email_lang field on Create Session.

​
Where these codes apply

The same set of codes is accepted everywhere a language is configurable: If the user’s browser locale is supported, the verification UI auto-detects it; otherwise it falls back to English (en). If you do not pass email_lang, emails fall back to en. All values are case-sensitive — use the exact codes from the table below.

​
All supported languages

The set below mirrors the keys of EMAIL_TRANSLATIONS in the service — both the verification UI and email-localization layers read from the same dictionary, so any code in this table works for both language and email_lang. Three languages render right-to-left in both the verification UI and emails: Arabic (ar), Hebrew (he), and Persian / Farsi (fa).
The validators that accept these codes are BaseSessionSerializer.validate_language and ContactDetailsSerializer.validate_email_lang. Both raise 400 with the message "Invalid language. Supported languages are: ..." (or "Invalid email language...") for any value outside the table above.

​
Picking a language for a session

The verification UI auto-detects the user’s browser language. When the browser language is one of the codes above, the interface and emails are served in that language. Otherwise the UI falls back to English. You can also set the language explicitly when creating a session:
If you only set language, emails still default to English unless you also pass email_lang. Conversely, setting email_lang does not change the in-browser UI language — the two fields are independent.

​
Country variants

Three codes are regional variants that you should prefer when you know your audience:
  • pt-BR — Brazilian Portuguese (use instead of generic pt for Brazilian users).
  • zh-CN — Simplified Chinese (mainland China, Singapore).
  • zh-TW — Traditional Chinese (Taiwan, Hong Kong, Macau).
The generic codes pt and zh are also accepted; the variant you choose only affects vocabulary and characters, not the underlying verification logic.

​
Requesting a new language

If you need a language that is not listed above, contact our support team. We can typically add a new language to EMAIL_TRANSLATIONS and the verification UI within 24 hours of your request — once added, this page is updated and the new code is immediately accepted by the API. Contact us via WhatsApp or your usual support channel to request additional language support.

Create Session API

Where language and email_lang are passed when starting a verification.

Update Session Status

Sets email_language for the status-change notification email.

Webhooks

Receive verification results — payloads include the chosen language.

Data Models

Canonical schema for sessions, contact details, and statuses.