API Additions and Changes 2018-01-09

api-update

(Mike Christianson) #1

Good day from Infusionsoft HQ! We’re happy to share the following additions or changes.

REST API

  • New Retrieve 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.

(Mike Christianson) #2

(Chuck Reed) #3

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.

Is this related to those changes?


(Dean Conomikes) #4

So like Chuck, everything was working fine yesterday as of 6pm EST 1/9

And now… error log lends towards the oauth2 no longer working? no clue how to even begin to move forward…

[10-Jan-2018 11:15:04 CST6CDT] PHP Fatal error: Uncaught exception ‘Infusionsoft\Http\HttpException’ with message 'exception ‘GuzzleHttp\Exception\ClientException’ with message ‘Client error: POST https://api.infusionsoft.com/token resulted in a 400 Bad Request response:
{“error”:“invalid_grant”,“error_description”:“Authorization code is invalid”}
’ in /home/vendor/guzzlehttp/guzzle/src/Exception/RequestException.php:113
Stack trace:
#0 /home/vendor/guzzlehttp/guzzle/src/Middleware.php(65): GuzzleHttp\Exception\RequestException::create(Object(GuzzleHttp\Psr7\Request), Object(GuzzleHttp\Psr7\Response))
#1 /home/vendor/guzzlehttp/promises/src/Promise.php(203): GuzzleHttp\Middleware::GuzzleHttp{closure}(Object(GuzzleHttp\Psr7\Response))
#2 /home/vendor/guzzlehttp/promises/src/Promise.php(156): GuzzleHttp\Promise\Promise::callHandler(1, Object(GuzzleHttp\Psr7\Response), Array)
#3 /home/vendor/guzzlehttp/promises/src/TaskQueue.php(47): GuzzleHttp\Promise\Promise::GuzzleHttp\Promise{closure}()
#4 /home/vendor/guzzlehttp/promises/src/Promise.php(246): Guzzl in /home/vendor/infusionsoft/php-sdk/src/Infusionsoft/Http/GuzzleHttpClient.php on line 73


(Mike Christianson) #6

Hey @Chuck_Reed and @Dean_Conomikes, hmm…

  • 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.)

Thanks


(Mike Christianson) #7

I’m beginning to think this is an issue with our API auth provider, Mashery. We’ll look into things, more.


(Chuck Reed) #8

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.


(Bradley Booth) #9

@Chuck_Reed can you provide the response headers you are getting. It helps us diagnose issues.


(Bradley Booth) #10

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.


(Bradley Booth) #11

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.


(Chuck Reed) #12

Still happening.

I just sent you the raw response headers for my failed XMLRPC request-- this one included some Mashery stuff. So maybe that’ll help you?


(Bradley Booth) #13

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.


(Chuck Reed) #14

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.


(Bradley Booth) #15

Ok, thanks. Can you pm me your client_id and I will see if I can trace it?


(Bradley Booth) #18

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.


(Chuck Reed) #19

Awesome.


(Bradley Booth) #20

Update: Issue with missing user context is now resolved. If anyone is still running into this please let me know.