Skip to main content
A
Anonymous
November 7, 2017
Solved

Activities API nextPageToken

  • November 7, 2017
  • 2 replies
  • 4268 views

I'm currently trying to debug a problem in our CRM integration where when scraping the API for activities changing, I'm getting the same results over and over.

In my CRM sync script, I start by tracking the last scrape attempt in a database. On the next run of the script, it provides that date (which is stored as EST then converted to UTC) to the paging token endpoint (/rest/v1/activities/pagingtoken.json).

In this example, I store the date as "2017-10-18 14:04:43" in MySQL then convert to "2017-10-18T18:04:43+00:00". After getting the paging token, I send a request to /rest/v1/activities/types.json and retrieve 300 activities for processing. The first activity date returned is "2017-10-18T14:03:10Z" and the last returned is "2017-10-18T14:03:26Z". If I run the script 10 times, I get the same datetimes over and over. The paging token is also always the same.

So as a sanity check, I fired up a REST client and crafted the exact same request to the pagingtoken.json endpoint and got a completely different paging token. I ran that request again & again and got the same token.

So at this point we have a repeatable "CRM" paging token and a repeatable "REST client" paging token.

Now when I take the paging token from the REST client and send a request to the types.json endpoint, the first activity's datetime is "2017-10-20T21:30:35Z" and the last is "2017-10-20T21:30:38Z".

Both of the clients use the same accessToken which is grabbed from "/identity/oauth/token" endpoint using the exact same credentials.

Can anyone tell me what is going on here?

This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.
Best answer by SanfordWhiteman

Same behavior if you use "Z" instead of offset "+00:00"?

This has the sound of malformed parameters.

2 replies

Kenny_Elkington
Adobe Employee
Kenny_ElkingtonAdobe Employee
Adobe Employee
November 7, 2017

Possibly a silly question, but when making a request for a new page, are you passing the value of "nextPageToken" from the previous response into the new request?

A
Anonymous
November 7, 2017

Not a silly question at all.

I run a request for the nextPageToken every time the script runs so it's "live" from Marketo. I never store that data for later, the only way for me to see it in the cron script is by stepping through with a debugger. It's saved as an object property which is accessed when sending the activities.json request to Marketo. Is that what you were asking?

SanfordWhiteman
SanfordWhitemanAccepted solution
Level 10
November 7, 2017

Same behavior if you use "Z" instead of offset "+00:00"?

This has the sound of malformed parameters.

A
Anonymous
November 7, 2017

Well it looks like this is the issue. I copied those datetimes right out of my debugger so I know the values being sent from Insomnia (rest client) were exactly the same as through the CRM, as far as I could see. I did a quick string replace the CRM and now I'm getting the same values as Insomnia.

I guess it's some issue with PHP or guzzle. Either way, it's working now. Thank you!

Terms & ConditionsAccessibility statement

Loading footer...