Field language
Paths, request fields, response fields and every value are English.
Paths and field names are English on both sides: what you send (projectId, scheduledFor, when) and what you receive (projects, name, createdAt). So are the values: format says caption_reel, status says generating, alignment says center, dayName says monday, an audiogram scene's type says bar_chart, and an error code says not_found.
There is no translation layer. The names you see are the names the system uses internally, which is why they cannot drift from each other: two tables to keep in step would mean the one nobody updates becomes the bug.
The one thing that is not ours
Your CONTENT passes through untouched, in whatever language you write it. A caption in Portuguese comes back in Portuguese; a palette you named yourself comes back exactly as you typed it. In the content.slides[].fields of GET /posts/{id} every field arrives as a pair: the field's name, which is ours and English, and its value, which is yours. You send that value back unchanged when you edit the slide.
One consequence worth planning for: a response example on this site may show Portuguese inside textContent or theme. That is content, in the language it was written in, and not vocabulary. Never branch on it.
Error messages
The envelope is { "error": { "code", "message" } }. code is the stable contract, and it is what you branch on. message is English prose meant to be shown or logged, and it can change wording without notice: safe to put in front of a person, unsafe to match on. See Errors.