There is this idea in the Ideas Portal, about being able to parse failed responses in Data Actions.
I was wondering why this feature is not implemented already. Is it too hard to implement? Is it that different from the successful response parsing?
What is worse is that in Call Flows, we cannot even get the Response Code. It is impossible to know if it failed because a 500, a 404, a 400... Why is this? What makes the Call flows different from the Message and Email flows in a way that it does not allow to catch the response codes in the Data Actions?
From an outside perspective, I do not get it. I'm curious about why this is like it is.
PD: Making the webservice respond with 200 OK and body {"statusCode": 404, "message": "Not Found"} is ugly and counterintuitive. And, of course, only possible if we had control over the external webservice...
The difference in error behavior between call flows and other flows is due to the system that executes the flows. Call flows are handled on the edges by a different, older, service than the service that handles the other flow types. I just pinged the product manager for the edge service about this continuing to be a pain point for customers.
There is a new feature approaching beta, "Functions", that allows a data action to run your own JavaScript code without having an AWS account. You could potentially call your endpoint from a function and then handle translating an error response there.
Thank you for your answer Jason. Although that new Functions feature looks awesome, using it for this would be another workaround. It would be nice if the Data Action failure processing were implemented as well (or at least, allowing us to capture the error data in the call flows like in the text flows).