Please, update the docs and make it more explicit

API Q&A
#1

++++++++++++++++++++++++++++++++++++++++
this part is about exchanging authorization code for an access token:
++++++++++++++++++++++++++++++++++++++++
Nowhere in the docs (link to docs, please click and read what I am referencing) is it stated that the parameters should be sent as part of form/x-www-form-urlencoded body when fetching an access token. Many APIs use POST request with parameters sent as query strings. Please clarify that your API expects parameters in the url encoded body.
++++++++++++++++++++++++++++++++++++++++
+
+
+
++++++++++++++++++++++++++++++++++++++++
and this part is about refreshing access token:
++++++++++++++++++++++++++++++++++++++++
Also, in the section about refreshing token, there’s this part:

Header:Authorization
string
The word “Basic ” (with a space) concatenated with a base64 encoded string of your client_id, a colon, and your client_secret passed via the Authorization header. Example pseudo code: Basic + base64_encode(CLIENT_ID + ‘:’ + CLIENT_SECRET)

which is not correct. I can refresh a token without this header. I can either send client_id and client_secret encoded in the specified way OR send client_id and client_secret as part of url encoded body; both ways work, and the second one (the non-documented one) is way cleaner IMO.
++++++++++++++++++++++++++++++++++++++++

Thanks for considering this,
Dmitar

#2

This isn’t very clear if you know what you’re asking or not. You reference the header for an authorization token but then are also talking about access/refresh tokens…which is it?

#3

There, I edited it.
Hope it’s now clearer which part is about access token, and which part is about refreshing it.

I mean, the part about about Auth header is in a quote block… I quoted the documentation that I linked above. Not sure what led you to think I don’t know what I’m asking about. (I’m actually not asking anything, I’m stating that you should update the docs which are not explicit enough and remove the parts which aren’t correct)

Thanks,
Dmitar

#4

Again, you’re talking about “refreshing a token without that header”…that header is for an auth token, NOT for access or refresh tokens…do you know what the difference between auth and access/refresh tokens are?..that’s what I’m trying to clear up because I can’t tell.

#5

Are you really asking me if I know what Authorization header is for? What do you even mean by auth token? It’s a common practice to send access tokens through Authorization header with the Bearer prefix.
I’ll just quote your own docs…

Quoting your own docs:

…
(from oauth guide)
Request an Access Token

The access_token is the token you will use to authenticate requests to the Infusionsoft API

…
(from rest api docs)
Each request to the Infusionsoft REST API must include an Access Token . You may provide your token one of three different ways; we recommend providing your token as a Bearer token through an Authorization request header.

Now to get back to my original post…
https://developer.infusionsoft.com/authentication/#refresh-access-token

See the last subheading? It isn’t correct. The Auth header with the mentioned content isn’t required; you can simply send client_id and client_secret throught url encoded form parameters. Docs aren’t up to date.
That’s the section about Auth header that I quoted.

By the way, I hope you’re not trolling… because I can’t tell either.

#6

You FIRST must get an auth token (which is NOT an access token and is handle in a separate process that uses the auth header)…you THEN must use the returned auth token to get a access/refresh token pair back and the access token you get on the SECOND call is what you use for api calls…that token is good for 24 hours. The refresh token is good for 6 month. Use the refresh token to get a completely different set of access/refresh tokens…because of this process, most choose to store and update these tokens in a db and run a CRON job to keep them refreshed every 24 hours…

Are you really asking me if I know what Authorization header is for?

Keep in mind that we aren’t paid to help you…and I don’t know you from Adam and we get all levels of questions and experience here…getting offended will not generate answers.