The following articles might be help to you.
The first one links to the HTTP Response section of the main HTTP Rule Action article describing how the HTTP Action includes the response data, status code, and error message that can be useful.
The most common approach when dealing with third party APIs with concerns about erroneous responses is to check the status code or the response data / error depending on how the API responds.
The second link is a more general purpose guide for Troubleshooting HTTP Action Responses but it shows real examples of using the data that gets returned by the HTTP Action for troubleshooting.
–
As with any troubleshooting effort, following the steps and tips in the Effective Ways to Seek Help and Troubleshoot guide is recommended.
Based on your screenshot, I don’t see any reason why the rule would retry things. A failed HTTP Action should not inherently cause the rule to retry. Nor does a failed expression where the resulting value would be something like «expression evaluation error», but the rule would otherwise continue.
That being said, I can’t see the rest of your rule nor how it’s triggered. Note that we do not officially support or recommend the variable looping approach. I know it’s a common approach in the community, but it’s not without its downfalls, especially if it isn’t configured with some general best practices in mind.