The API answers in Spanish or English. The language affects only text meant for people; contract identifiers never change.
Spanish is the default language.
Negotiation
An integration sets the language with the standard header:
Accept-Language: enThe header takes precedence over any other signal. When absent, resolution continues with the preference stored on the account and, failing that, the default language. An unsupported value produces no error: the request is served in Spanish.
What is translated and what is not
| element | translated |
|---|---|
An error's detail | Yes |
| Documentation titles and descriptions | Yes |
An error's code | No. It is the contract |
Field names (clave_rastreo, created_at) | No |
Enum values (not_found, auto_disabled) | No |
| Identifiers, amounts and dates | No |
The practical rule: if a value is compared in code, it is not translated; if it is shown to a person, it is. That is why branching happens on code and never on detail, as the error contract sets out.
Translation coverage
Not every error code has translated text yet. When it is missing, the response returns the original text rather than a gap: the detail stays readable, but may arrive in the language it was written in. The code is unaffected, so an integration branching correctly notices no difference.
Documentation
Reference pages exist in both languages and share an identifier. Switching language in the documentation does not change the contract: field names, enum values and error codes read the same in either one.