Unable to access response body when response is outside 2xx in Appfarm

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).

Hi Kris, and welcome to the Community!

Thank you for the detailed question. Please do share the log details that you have with me via DM, and I will forward this on internally.

Rhys

Hi Rhys :slight_smile: As you can tell, I’m new to the community. How do I go about DM’ing you? I’m sure its obvious, but I can’t see it right now :smiley:

Hi,

I sent you a DM now which you should be able to reply to. You should be able to find this under “My messages”

Rhys

FYI, there is no “My messages” in my side menu, but I was able to reply to your message yesterday by finding it in my notifications. Did you receive my response?

For anyone interested, this is whats happening:

When using Appfarm’s Static IP feature (like we did here), error responses from backend APIs (status codes outside 2xx) are not forwarded transparently. Instead, the Static IP server returns a generic 500 error and hides the original status code and response body. This makes proper error handling difficult for clients.

3 Likes

A challenge has been registered internally on this, and this thread will be updated with further information in due course.

1 Like