Hi everyone. I'm looking for some clarification on the

async-*

SOAP operations and how they relate to concurrency. It seems to me that using

async-*

operations will return a

jobId

as quickly as it can, completing the API request and no longer counting toward our maximum concurrent requests even though the work isn't finished. We would then need to make at least one (maybe more) request to

checkAsyncStatus

for the job. Once the job is completed, another request to

getAsyncResults

to get the results of the job. Granted, these requests would be faster since none of them are being held while the actual work is being performed. So the balancing act seems to be: does the overhead of multiple API calls for a single list action outweigh the time it takes to process the data. It seems that performing a

updateList

operation with a single record might affect concurrency less than an

asyncUpdateList

operation with subsequent

checkAsyncStatus

and

getAsyncResults

. But with 200 records, I can see the benefit. Is my understanding of this correct or am I over complicating that balancing act and use async operations when possible?

async requests arent meant to be faster

Understood. I would expect my servers to continue working on other requests after the jobId is returned. I guess the biggest thing I was trying to confirm was the first part. Once the jobId is returned, the work being done doesn't count against concurrent requests. We're pushing the limits of our concurrency and barely use

list

operations at all and if we're going through the process or changing our integrations I'm wondering if we start defaulting to async operations when appropriate.

nobody likes list operations

Thanks, @battk