I have run into similar issues when working with Web APIs. The structure of the JSON is different on success vs. failure or depending on the parameters.
Identifying the variability in the responses is tedious work.
Here are some blocks illustrating my approach:
First, check the error block. The error block is NOT a web service error, but a Thunkable internal error. I don’t think I’ve ever had a error that wasn’t null
Next, check the status. HTTP standards indicate series 200 codes are generally successes, while 400s are errors. For illustrative purposes, I’m assuming anything but 200 is an error. Your web sevice may be different.
Next, I check to see if the response is actually JSON by converting it to text and checking for {. This works even if the response is plain text. But it prevents errors that can occur if the response is NOT JSON.
Now that you have verified that the response at least MIGHT be JSON, now convert it to an object and check to see what properties are available. Sometimes the properties will change depending on the response. Some web serivces will even return a status 200 AND a response object that indicates there was a problem with the parameters. In this illustration, I first check to make sure the expected property exists. This will prevent errors associated with missing properties.
Again, this is not an exhaustive debugging routine, but it should give you an idea of how to validate the response BEFORE processing.
Happy Thunking!