Has anyone encountered a REST call that returns successful, returns moreResults = 1, but doesn't return any results? I'm setting up a warehouse to log all of our interesting moments and am backfilling it to start with. For the most part this has worked fine, but there's a certain period of time that I run into the problem I described -- 0 results, yet there's no errors, success = 1 and moreResults = 1. Additionally, I know for a fact there's results, as I can change the paging token to a month later and it pulls results just fine.
Could this just be a load issue at that particular time of the call? Or has anyone else encountered something like this?
Solved! Go to Solution.
That's expected behavior -- there are a couple of threads about this. It has to do with the way the cursor (paging token) paginates results. Unfortunately, it does mean you will spend API calls where there are no results, but if you continue to chase the next token you should be fine.
That's expected behavior -- there are a couple of threads about this. It has to do with the way the cursor (paging token) paginates results. Unfortunately, it does mean you will spend API calls where there are no results, but if you continue to chase the next token you should be fine.
Got it -- did as you said and it eventually got through them. The period of time it was getting stuck was before I came aboard and there must have been a significant change to our instance since I didn't encounter any kind of slowage like that any other time. I assume the archived activities it won't return are activities for deleted leads?
Not completely sure of the reason(s) for the gappiness. It's been said that it's a load-shedding measure, but that doesn't make much sense to me... maybe that plus an algorithm that guesses the cursor forward into a massive table and sometimes misses.
It appears you were only interested in 1 activity type: Interesting Moments. However, if you wanted to download more than 1 activity type (up to 10), it's best to make a call with all activity types, rather than 10 separate processes, each for only 1 activity type. That way, it is likely to have fewer gaps and return more returns in each call, resulting in fewer API calls.