Access user token without using Oathflow


I have been asked the following by our developer, can anyone point us in the direction of any threads that might help?

I Based on the documentation it looks like we need to take the user through an OAuth flow in order to get an access_token to use the api and get details down from the authorised user.

In our app the log-in will be entirely server-side with the user only providing an email and postcode and therefore an OAuth flow is not possible, do you have any way to get down a user token without using an OAuth flow?


OAuth is independent of your server side details. Although you would need to manage the refresh cycle on the server side, the rest is handled by Infusionsoft’s authentication servers. I have a video that covers all of this that might help.

We are unable to request access token.

We are using the article bellow to request access token.

This is the curl that we have compiled while following the article below: curl -X POST -d ‘client_id=xxxxxx&client_secret=xxxxxx&code=xxxxxx&grant_type=authorization_code&’

We get this response: {"error":"invalid_grant","error_description":"Authorization code is invalid"}

When we try to give wrong grant_type (for example 123) the response is: "error": "unsupported_grant_type"

When we do not give any grant_type the response is: "error_description": "response_type or grant_type is required"

We are not sure how to resolve this problem, can you/someone please advise?

(also screenshot attached for reference)

(Edited to remove keys: You will want to regenerate your key/secret pair as a security measure. Treat keys as passwords.)

Your grant type can only be “full”. That is all that will work with it right now.

Here is a reply from my developer for the conversation. Can you please add it into the discussion:

We have tested grant_type=full using this curl:

curl -X POST -d ‘client_id=xxxxxxxxx&client_secret=xxxxxxxxx&code=xxxxxxxxx&grant_type=full&’

The response is:

{“error”:“unsupported_grant_type”,“error_description”:“The authorization grant type is not supported by the authorization server.”}

We are using this documentation: OAuth2 Authentication - Keap Developer Portal and attempting to get the access and refresh tokens using this api. Do you have any other suggestions?

(Edited to remove keys: You will want to regenerate your key/secret pair as a security measure. Treat keys as passwords.)

Sorry, the grant type should be authorization_code. I was getting the code parameter mixed up with the grant type. authorization_code is what you’ll need to use.

Did you manage to get this sorted?
I’m having the same problem.

Even using grant_type=authorization_code

Post the code snippet if you can? The most common thing this happens with is because of the difference between and auth token and access token. With the code to look at it would be easier to determine what’s happening.

Hello, I capture the oauth code but when I try to get the access token I always get this error:
“error”: “unsupported_grant_type”,
“error_description”: “missing or unsupported grant_type”
with grant_type = authorization_code.

&code= (received code by oauth)

Those values are required to be in the post body as x-www-form-urlencoded

you don’t provide the grant type by POST/GET params. Put the request in the request body.

I’m having same error here my code

const { code } = req.query;
const body = JSON.stringify({
‘client_id’: CLIENT_KEY,
‘client_secret’: SECRET,
‘code’: code,
‘grant_type’: ‘authorization_code’,
‘redirect_uri’: ‘http://localhost:3000/oauth/redirect

try {
const response = await fetch(, {
method: ‘POST’,
body: body,
headers: {
“Content-Type”: “application/x-www-form-urlencoded”
const result = await response.json();
} catch (err) {

but it gives me {“error”:“unsupported_grant_type”,“error_description”:“missing or unsupported grant_type”} 400 status code

Response type and grant type shouldn’t be in the same call so I can’t tell which step of the process you’re on. Authorization or token request. The video below covers this in php but the process is still the same. Give it a watch because the most common mistake is to confuse the permission step with the access step.

OAuth Docs in image as well: