I’m building an application that utilizes the UPS Rating API. Currently, the API provides two different responses; a status code 400 yields a different response than a status code 200. However, I want to be able to store the response even when the status code is 400 because these errors are relevant for logging purposes.
I’ve attached images showing the different responses and how I’ve integrated them into Triggre. While the 200 response is being received correctly, the 400 response isn’t. Even when I create a separate API call and only include the status code 400 response in the response body, I can’t iterate over the errors. What would be the solution for this?
Thanks in advance,
That’s an interesting problem Thanks for providing so much detail!
Have you tried explicitly using error code 400 on the decision? Since you use any other value that might be the reason.
Though I think this should work, so I will get the team to dive into this regardless.
Hope that this will solve the issue at least; please let me know if that works. I’ll check back in when I know more.
I haven’t tried incorporating the error 400 code into the decision, but I successfully generate an application log after the decision is made. However, in the ‘Loop Over Errors From Response’ action, although I include a ‘create application log’ action, it doesn’t seem to execute the loop over the errors.
I have checked with the team and currently we only map the json outputs if the response status code is 200 or 201. The reason for this is that there are webservices that respond with a different type of data in case of a 400 error.
That being said, we are looking into a way to improve this in a future release so that this case can be more easily handled. Sadly for now, I don’t see a way to handle the errors since we simply don’t map them it seems.
Thanks for checking with the team. It’s good to know the current status, even though we’re facing a limitation with the 400 errors.
Thanks again for your assistance.
You’re welcome! We are discussing this topic in our meeting tomorrow, to see if we can come up with a good solution. I will let you know if we do, and whether we will be able to pick it up in an upcoming release.
We just discussed it, and will include this feature/fix in one of the next releases.
It depends on the subscription of the application you are working on, when exactly this feature is available for it.