You don't have to block the complete UI before the response comes back. You only have to disable the parts of the UI which allow to make another API call before the first one is processed completely (in an asynchronous operation, of course!).
If that is feasible or not depends heavily on the UI, the features of your application and how they are tied to those API calls.
the overhead of dealing with a second async call to the API before the first one responds is also difficult to maintain and to write
You might also rethink why this is the case, and if it is really so difficult as you say. I assume your UI is already event driven. So it has to deal with all kinds of events from different sources coming in in arbitrary order. A "respond event" should not be different from this, the only thing you have to make sure is any respond event does not rely on some global state caused by the related previous request event. Instead, the whole information package you get from a respond event should be self contained, not relying on the fact the latest former "request" event was exactly the one which belongs to the next incoming respond. If this is possible depends on the API and how it is integrated into your system in detail.
Indepently from allowing the users to initiate multiple API requests before the responds come in, or not, there should be some visual feedback in the UI informing the user about the open requests. Disabling the API related parts in the UI until the request comes in is probably the simplest form of giving the user this feedback. If you want to allow API requests without blocking the next one, the user should still know the "button he pressed" to initiate the request (for example) was sucessfully hit by him. The UI may show a list of open requests, an increased counter, maybe a progress bar or something like that, so he does not try to press "the button" several times to force a reaction.