Arduino IDE and ESP8266 WiFi Device: Creating records in Backendless but also getting 400 Bad request errors?

I am using the Arduino IDE and an ESP8266 WiFi device for logging IoT data to Backendless.
It is correctly logging the data I want into a Backendless table, however I still get a “400 Bad request” in the HTML response. Why would Backendless correctly create the record and then respond with the error 400?
ps: I use the SHA1 fingerprint for the HTTPS request.
Please advise.
Below is a trace from the IoT device:

Using fingerprint '4E AA 6E 90 2B F3 69 B9 25 15 02 F4 92 BA 74 24 FB 16 0B 83'
HTTPS Connecting
Connected to web
requesting URL:
POST /api/data/IoTDataLog HTTP/1.1
Content-Type: application/json
Content-Length: 71
{"Litres": 1.5, "ownerId":"xxxxxx-16D1-4861-BB6B-D31EB132B1DC"}
Connection: close
request sent
headers received
reply was:
HTTP/1.1 400 Bad request
content-length: 90
cache-control: no-cache
content-type: text/html

connection: close

<html><body><h1>400 Bad request</h1>
Your browser sent an invalid request.

Hi @Tony_B

try to build and run a curl

This is what I get.
This code is slightly different to that used in the original post, but the result is the same.
So this seems to work? But not from the IoT Device.
Please advise any other settings I need?

curl -H Content-Type:application/json -X POST -d "{\"Device_QR_Code\":\"CMDD5001000\", \"IP_Address\":\"xxx.168.8.143\", \"Temperature\": 21.5, \"ownerId\":\"xxxxxx-16D1-4861-BB6B-D31EB132B1DC\"}" -v
Note: Unnecessary use of -X or --request, POST is already inferred.
*   Trying
* Connected to ( port 443 (#0)
* schannel: disabled automatic use of client certificate
* ALPN: offers http/1.1
* ALPN: server did not agree on a protocol. Uses default.
> POST /api/data/IoTDataLog HTTP/1.1
> Host:
> User-Agent: curl/7.83.1
> Accept: */*
> Content-Type:application/json
> Content-Length: 133
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< server: nginx
< date: Fri, 14 Oct 2022 04:02:08 GMT
< content-type: application/json
< content-length: 325
< access-control-allow-origin: *
< access-control-allow-methods: POST, GET, OPTIONS, PUT, DELETE, PATCH
< strict-transport-security: max-age=86400
Connection #0 to host left intact

Ah, I see:
In the original example I copied there was a “Connection: close” included with the data.
This ended up in the JSON data.
I’ve removed this and included the “Connection: close” in the header (as it should be) and this works now.