Yeah, we already have created a ticket to update the docs. To be clear the spec does allow for accepting client credentials as application/x-www-form-urlencoded in the body but describes it as MAY not MUST so when I communicate to people I always steer them to the Basic Authorization header, especially when I read stuff like below. We use a 3rd party to handle our OAuth token processing so if there ever decide to change something I like to be conservative with the spec so we can hold them to it. Anyhow long winded apology for you are right Glad everything is working now for you. If you run into anything else don’t hesitate to hit us up.
Including the client credentials in the request-body using the two
parameters is NOT RECOMMENDED and SHOULD be limited to clients unable
to directly utilize the HTTP Basic authentication scheme (or other
password-based HTTP authentication schemes). The parameters can only
be transmitted in the request-body and MUST NOT be included in the
request URI.
Make sure your client_id and client_secret are correct (If they work in the interactive REST docs then you should be good). Also make sure the Content-Type is application/x-www-form-urlencoded. The proivded auth header, code, and redirect_uri are for example. Make sure your redirect_uri is the same one you used to get the code. If you still can you give us the entire response including headers?
Actually I was using request-promise library to send the POST request.
It said its using:
Content-Type: application/x-www-form-urlencoded
, but it was not.
I switched to basic https npm module from node it started working.
Also, I am not sure if the InfusionSoft server is able to understand
Content-Type: multipart/form-data;
with boundary.
Thanks for your help. Please have the documentation updated. Its not that starightforward as it is documented.
Example: Getting access token needs cleint_id and secret in Auth header but documentation says it should be a param. Refresh token’s documentation is correct.
@Himanshu_Phirke we are currently updating those docs and should be accurate on the next release. Unfortunately the /token endpoint is not an Infusionsoft server, it is our OAuth vendor Mashery. That is the main reason I urge everyone to stay as close to spec as possible, even if it works another way. Super happy you got it workin. Let us know if you need anything else.
Thanks for your help @bradb.
My next job is to get tagged contacts via xml-rpc as REST does not support.
So a quick question, can I use the access token of oauth for XM-rpc calls? The documentation says so, but if you could provide a feedback, would be helpful for me