The usual approach is to define an error handler in the microflow where you do an additional API call to undo any previous call, but this requires the service to have an API to undo the earlier API call.
This can be quite challenging indeed. In general my advice would be to keep the microflow calling the API and storing the request and response as small as possible and separate it from after processing, to minimize chance on errors. You could consider to box this in a microflow and execute in its own transaction (using queues or Java actions).
If you want to keep it simple: make sure your after process doesn't error xD And add separate error handling to that part, such that only the after process can be restarted or you can make an API-call to undo stuff (which is quite rare in my opinion).
In the extreme: even your error handler could cause errors (for example: your database cannot be reached), so having 100% consistency is hard to guarantee.