We’ve built our own REST API towards our on-prem CRM-system (“powin-api” hosted in our Azure). We’re caching the access token in a seperate Appfarm service, for use with all web requests towards “powin-api”. Everything is fine as long as the web requests responds within http status code 2xx. The problem is when the API responds with e.g. 400 or 409, we’re unable to access the actual API response body when doing “Catch Web Request Error”:
(I’ve also tried setting 400, 401 and 409 in “HTTP Codes”, Action Settings):
For example, powin-api responds with http status code 400 Bad Request, and the following Headers and Response body:
content-length 221
content-type application/json; charset=utf-8
date Fri, 09 Jan 2026 14:17:47 GMT
etag W/"dd-+QjVMa8tQuPX2gBL3W90yKXrvjo"
request-context appId=cid-v1:
{
"description": "fail",
"errors": [
{
"message": "Invalid 'orgno' (you provided b). It contains invalid characters: b. Only numbers and whitespaces are allowed. Example: 123456789 or 123 456 789 as either string or integer."
}
]
}
Viewing such responses outside 2xx is not a problem in all other clients, like for example Bruno REST client:
It looks like this issue was raised several years ago: Read response when catching web request error . This thread is marked as “Solved”, but people are clearly still having this issue, of not reaching the actual response body. According to your Docs Catch exception | Appfarm Documentation it looks like it should be possible to catch specific web request exceptions like http status code 400 or 409, and then access their body with dot notation. But we are not able to do this in this case. Why not? Is there some good reason to make the respons body unavailable for developers? This is quite frustrating. APIs often have a good explaination of what went wrong when not returning 2xx OK, I don’t understnad why this information should be hidden.
One use case we were going to implement was the following:
When a new customer in one of our Appfarm solution should be created in our CRM system, if that customer (organization number) for some reason already exists, “powin-api” returns a 409 Conflict, with the follwing response body. We would then be able to respond to the 409 and simply map the body.data.customers[0].KUNDENR (customer number) to the Customer object in Appfarm.
{
"description": "fail",
"errors": [
{
"message": "One or more active customers already exists with given FORETAKSNR."
}
],
"data": {
"customers": [
{
"FORETAKSNR": "123456789",
"KUNDENR": 1001331,
"NAVN": "Contoso TEST AS",
"AKTIV": 1,
"REGISTRERTDATO": "2026-01-09",
"SLUTTDATO": null,
"OPPSIGELSESDATO": null
}
]
}
}
To me it looks like Axios is throwning an error in Appfarms Node.js Express backend. The log details from Appfarm DevTools indicating so (I can send it to any Appfarm employees in a DM).




