I'm trying to retrieve segment subscription counts, lets say I have 40 lists and each list has 5 segments in it.
I need to present a tabular view in my app of the number of of subscribers in each segment for each list - so the final view has a row for each list and a column for each segment - 200 data cells in all
With the current API and the way that segments have a separate data model to lists the only way I can see to do this goes something like this:
For each list: GET list segments For each segment GET subscriber count end for end for
So that gives me 40 GET requests to find the segment IDs and 200 GET requests to get the subscriber counts in each segment.
So that's 240 API requests to get 200 integers - it's slow to say the least.
Am I missing a really obvious solution here? Is there an better way to do this eg an alternative query that just returns the segments counts given a list id, that would at least let me drop the calls back to 40???
As mentioned on Twitter there isn't a better option available currently, but we've added your vote for returning the subscriber counts for all segments in a list, in a single request.
The lack of ability to do bulk operations is actually proving really frustrating, if you want an example of a real world application using your API that's been hit on several fronts by this then feel free to get in contact with me!
We're definitely aware of the need to improve our API in several areas in this regard. Particularly when it comes to unsubscribing people from lists, etc.
One minor effeciency you can already introduce is to get all the segments belonging to a client. If you're caching the list information that would save at least your first 40 calls.
But we'd love to here if there's other bulk operations that you have a particular need for (other than getting all the segment counts, which you mentioned before.
Well on the write side of the equation have a look at http://www.campaignmonitor.com/forums/viewtopic.php?id=6522 for the other side of the problem.
In some ways what I'm really seeking from the API is a query format of some sort so I can do both more complex reporting, but also to allow for the set up and tear down of client accounts that need a specific structure - making any sort of app that hits the API means that I will always need a certain structure of custom fields and lists on a client account and currently the silo model that's exposed via the API just makes it impractical to do anything slightly complex.
To deal with the integer problem above I've had to cache results aggressively and still cut the pagination on my app back to only 5 records per page - loading up any more without a primed cache times out PHP on a typical shared hosting account.
Unfortunately I can't cache all the write operations for the initial list setup! So I'm stuck at a user experience that sets up one list at a time, or I dive deep into ajax triggered callbacks to work around all the time out issues.