Good day from Infusionsoft HQ! We’re happy to share the following additions or changes.
REST API
NewRetrieve User Info: Retrieves information for the current authenticated end-user, as outlined by the OpenID Connect specification.
Fixed a bug when using List Contacts: order is now used; prior to this fix, order was ignored and results were always sorted by id.
XML-RPC API
Fixed a bug when retrieving Lead Source ROI Report via SearchService.getSavedSearchResultsAllFields with Roi, Visitor to contact, or Contact to customer Lead; prior to this fix, it returned an error with [Unexpected]Unable to get saved search results.
Yesterday, my app was working flawlessly, this morning I get “Error: XML-RPC fault: [InvalidParameter]Unable to obtain global user ID from request for: (my appname)” whenever I try to call the getUserInfo XMLRPC method.
The Retrieve User Info for REST was actually added over two weeks ago. We were belatedly announcing this one.
The fix for Contact list order was actually released over three weeks ago. Again, we belatedly announced it.
I’ll look into our third change (the XML-RPC fix), shortly.
In the meantime, would you both let me know what requests you’re making (path, payload, captures if possible)? And, approximately when you began encountering problems? (Be sure to remove any private or proprietary information before posting.)
Last time we had a similiar issue, that’s what it was as well-- something with Mashery.
I’m having trouble making requests via OAuth on both REST and XMLRPC.
Via REST, I get “Access denied,” regardless of which path I request (I tried oauth/connect/userinfo and /contacts, both in my app and in the interactive docs.). XMLRPC is more hit-or-miss.
To be clear the new REST retrieve user info endpoint is not the same as the xmlrpc one. @Chuck_Reed is referencing the xmlrpc one and @mike.christianson is talking about the new REST one. I have done some testing though and I am able to successfully get a new access token via and authorization code grant. I am getting a 403 on my test call. That 403 is originating from Infusionsoft not Mashery. I am looking into why. It is possible Mashery is not sending the request to us properly, but I am looking at it right now.
Just I as finished my reply. I retested again with the same test call and it is now working. Can everyone try again? If it is working let me know so I can contact Mashery with the details and try to get a root cause.
Is that with a previous access token or a brand new one? The headers show the error is being provided by Infusionsoft. I am thinking Mashery is not passing up us the user context, but I am still running that down.
Brand new token, that request is made the instant we get a successful authentication via oauth. It was less than a second old when that request was made.
Update: It has been verified that Mashery is not passing us the header that contains the user_context of the access token on certain calls. We are not sure why it works for some cases but not others. We have opened a Critical case with Mashery to get it resolved. I will update when I have more information.