Out of the box there is not solid solution without some level of coding. Either route requires making another mbox call unless you hold up the first one which might impact the user experience.
Here are the two options I have entertained in the past:
1. Use an Adobe Launch rule to listen to a custom event or data element related to the data you are waiting from the API. Then fire another Adobe Target global mbox with the parameters including the data you need for Target to qualify the user for the experience. I have seen where the rule might actually live right in Adobe Launch that way you only call Adobe Target if needed and thus not needing to make multiple calls. Only in Launch can you fire multiple global mboxes for some reason which makes this one more appealing for those who want to minimize coding in Target experiences.
2. User the parent/child approach. This is when you create a "parent" experience which is going to be targeted to everyone essentially on the page in scope. In this experience you have an event listener or data element listener waiting for the data from the API and then you can chose again to execute your logic on the client side to decide if to call another mbox or just fire getOffer/applyOffer function with the parameters needed with the custom mbox name. With this approach you would then have form-based edited experience with the custom mbox name being targeted to users with the parameter key value pair needed to qualify.
Let me know if you need any more details.
Best of luck!
Jose
