Getting wrong values for API request with language header

I have…

I’m submitting a…

  • [ ] Regression (a behavior that stopped working in a new release)
  • [x] Bug report
  • [ ] Performance issue
  • [ ] Documentation issue or request

Current behavior

We have an Angular application that serves clients all over the world, this is the app url:

We’re sending a request to Squidex API in order to get localized values, we’re sending requests to this API: '‘
we’re sending a GET request with the following headers:

x-languages: ar

unfortunately, we’re not getting the right values from Squidex, we’re getting values for a different language.

Expected behavior

we would like to get the correct localized values

Minimal reproduction of the problem

Navigate to:
select Arabic or any other language, open Network tab in the browser and examine the outgoing API request.


staging & prod

App Name:
Mine - Privacy Center

  • [] Self hosted with docker
  • [ ] Self hosted with IIS
  • [ ] Self hosted with other version
  • [x] Cloud version

Version: [VERSION]


  • [x] Chrome (desktop)
  • [x] Chrome (Android)
  • [x] Chrome (iOS)
  • [x] Firefox
  • [x] Safari (desktop)
  • [x] Safari (iOS)
  • [x] IE
  • [x] Edge


What do you mean with other language? Usually it falls back to the master language.

We have multiple languages:

So in order to get values for our labels, we’re sending x-languages header with the user’s local language.
But we’re always getting the same result, feels like we’re getting a cached result… if for example, we’re sending header x-languages: ar we’re getting values relevant for a different language (for instance French)

Due to the fact that we’re talking about a Production environment, we had to make a small patch for the meantime, so we’re sending each request to Squidex with an additional header:

cache-control: no-cache

If we don’t send it, we’re getting wrong values.

Do you use the CDN? Because there is no caching I am aware of. Or do you have your own cache layer?

As you can see in the example Omer shared, we are using:… which is not the CDN.
We don’t have our own caching layer.

I understand it now, it is the etag system that causes some problems here. I fixed a bug with that and it was causing this issue. Your workaround is correct for now and I hope I can provide a better until end of next week.