Dmitry, The reason why this is difficult is that SmartLists are dynamic and changing all the time. Let's say you have a smart list looking for everyone who visited a web-page in the last 6 hours. Let's say 10K leads qualified at instant t1. The SOAP interface only allows you to extract 1000 leads in a batch, so by the time you extract the first few batches, the smartlist could have 10,500 leads (10K + leads that qualified - leads that got disqualified). There are two ways of dealing with this and they both have problems -
1. Take a snapshot of the smartlist at t1 in which case the resultset is the set of 10K that qualified at t1 and send this to the customer application 2. Allow the size of the resultset to change dynamically, but this leads to all sorts of problems because leads could go in and out of smartlists.
#1 is no different than forcing you to push the info into a Static List. I can see why you do not want an intermediary static list, but from our standpoint it is better to use a static list. This is because you are consciously creating snapshots that you want to query. If we were to implement option #1, we will have to keep the snapshot around for a certain amount of time and this takes up server side resources.
.png)