API request encoding matters

When you submit data to an API, the character encoding is crucial to ensure that the data is processed properly, especially if you’re working with UTF characters.

Consider the following HTTP request:

POST http://api.ecs.eu/feedback
Content-Type: application/json

{
  "id": {{$randomInt 9 1000000}},
  "feedback": "🫠",
  "date": "{{$datetime iso8601}}"
}

Notice, that the content-type is set to application/json without a specific encoding, and the feedback property contains an emoji. Most likely, the API will respond with something like:

HTTP/1.1 201 Created
content-type: application/json; charset=utf-8
Content-Length: 82

{
  "id": 972680,
  "feedback": "🫠",
  "date": "2025-06-16T11:33:28.326Z"
}

Notice how the contents of the feedback property are broken. This is caused by the lack of encoding in the request. To fix this, extend the content-type header with the encoding:

POST http://api.ecs.eu/feedback
Content-Type: application/json; charset=utf-8

{
  "id": {{$randomInt 9 1000000}},
  "feedback": "😎",
  "date": "{{$datetime iso8601}}"
}

Now, the API will respond with the correct encoding:

HTTP/1.1 201 Created
content-type: application/json; charset=utf-8
Content-Length: 82

{
  "id": 972680,
  "feedback": "😎",
  "date": "2025-06-16T11:33:28.326Z"
}

This issue caught me off guard while presenting how to use Dev Proxy to emulate CRUD APIs at the recent European Cloud Summit. While I was first suspecting an issue with Dev Proxy, it turned out to be a misconfiguration of the client that I was using to submit the request to the API.