Activities API strange response

[Anonymous]

Hey,

I am trying to replicate the Interesting Moments section through the API.

I am able to get an access_token via client_id and client_secret. I am able to get a Marketo ID via SFDCLeadId. I am able to get a pagingtoken via sinceDatetime.  (used July 1 2017) Looking at Salesforce I am able to see this Lead has interesting moments since July 1 2017.

Then I try to use this callout to return activity data for this lead:

rest/v1/activities.json?access_token=xxxxxxxx&activityTypeIds=46&nextPageToken=yyyyy&leadIds=12953232

This is the response:

{

    "requestId": "aab4#xxxxxxx",

    "success": true,

    "nextPageToken": "abcdxyzxxxxxxxxxxxxxx====",

    "moreResult": true

}

Questions:

Why isnt the Interesting moment that I see in Salesforce displayed here?

Why is the moreResult attribute true?  Even though no results are returned... If I use the new nextPageToken in another callout as you would in a more than 300 results situation, I basically get the same response, no real results but a new nextPageToken is given and moreResult is still true.

[SanfordWhiteman]

It's common to see moreResult as true with an otherwise empty response. It's because of the way the back end db is paginated.

[Anonymous]

If that is true, how shall I know when all results have been returned?

I thought that pattern was to keep calling out until moreResults returned false.

https://developers.marketo.com/rest-api/lead-database/activities/#page_through_results

Regarding my other question, any idea why the results are empty even though I can see Interesting Moments in Salesforce?

[SanfordWhiteman]

Keep paging through until moreResults is false, yes.

The results aren't empty, they're empty for this page of overall Activity results.

[Anonymous]

OK.  This seems strange to me.

Its as if the API are returning 300 activities without regards to the leadIds filter, and then filtering the 300.

I thought I would only have to call out again if the lead I was querying had more than 300.

I am nervous about this because the callouts where leadIds are specified take much longer than callouts where leadIds are not specified... even when results are empty.

Thanks for your help.

[SanfordWhiteman]

Yeah, it's the way it cursors through the db. Obviously suboptimal but you're doing everything right.

[Steven_Vanderb3 · Accepted solution]

Think of it like this.  You've asked your intern to grab a copy of Harry Potter and the Sorcerer's Stone and notate every page and sentence number that mentions Professor Snape.  You've also told him every 15 minutes he needs to check in with you and report what he's found so far and where he stopped in the book (you've had bad luck with interns goofing off in the past).  The first few check-ins he brings you a blank piece of paper and where in the book he stopped; Snape isn't introduced immediately so there's no mention for him to document but the intern continues to read.  Eventually you'll start getting a couple references, then many references, with the volume ebbing and flowing depending on how much the story focuses on Snape at any point in time.

That's basically how that endpoint works.  It pages through all the activities in the database looking for what activities qualify for what you specified.  Sometimes it finds none in the amount of time the call is allowed to stay open but it comes back, returns a pointer of where it stopped, and says it's not done searching yet.

The alternative is having your intern run a digital copy of Harry Potter through a script that spits out all the page and sentence numbers in one go.  That's kind of like how the Bulk Activity Export endpoint works.

[Jamie-Carey]

slow clap​

[Steven_Vanderb3]

If you're looking to intern at my company that writes Wikia pages detailing the life and times of Severus Snape, it's worth 4 college credits and all the butterbeer you can drink.

[dkreitter]

Most entertaining explanation I've seen on the community in a while. Nice one, Steven!