I don’t think there is an issue with API execution performance here, but just the reality of how actions are deployed and reported on within BigFix.
You should be able to get rid of the 30 sec delay between steps 1 & 2, I’m not sure what that is providing unless it is a retry delay for when the server is not running.
At step 2, this is actually generating the action and distributing it through the infrastructure to the targeted endpoints. The API doesn’t change how this process works, the same thing would occur if you deploy an action in the console. It needs time to be gathered and evaluated by the endpoints, before they can report back any status. The default minimum reporting interval for clients is also 60 sec for most deployments, so you shouldn’t expect to get a response back much faster than a minute.
I’m not sure what the difference is between steps 3 & 4, but depending on the size of the download and runtime of the action being deployed, it could take several minutes to complete on each client, so you would need to keep querying for action results (with some reasonable delay) until every targeted client reports its final status (usually Fixed or Failed).
IMHO, expecting an action to be sent to, executed on, and results reported back from a remote endpoint in less than 60 seconds is not reasonable for BigFix or any similar product.