First party API access

[Scott_Bennett]

My company has chosen Infusionsoft as our CRM and we need to be able to do server-to-server communication with the Infusionsoft API. The OAuth 2.0 spec allows for client_credential grant types to allow for server-to-server first party application communication. Does the Infusionsoft REST API support this? If not, this may be a show stopper for us and will require us to seek out a different CRM provider.

To be clear, we are not developing an application for the Infusionsoft Marketplace. This is solely to allow our server application to access information within our own Infusionsoft account. If client_credential grant types are not supported, what is the recommended way to handle this scenario?

[mike.christianson]

Hi @Scott_Bennett, have a look at these prior conversations. I think it should get you going. If not, come back and let us know!

Integrate APIs from backend services

Hi @Chalani_Peiris, there is a way to generate an access and refresh token without going through the OAuth flow. If you go to https://accounts.infusionsoft.com, there will be an “API Access” link next to each of your Infusionsoft accounts. Click on that link, enter your client id and secret from here, and an access and refresh token will be generated. Edit: I would also recommend putting the access token in the auth header rather than as a url parameter. See the “Making Requests” section of the…

Oauth without a website

If you have a client_id and client_secret you can use something like postman to run through the authorization flow with out a backend. You can also generate an access token / refresh token pair from Account Central (https://accounts.infusionsoft.com). Click API Access next to the account you want access to.

[Scott_Bennett]

Thank you for those links. I had reviewed those threads already and I also found this article on your site: Making OAuth Requests Without User Authorization - Keap Developer Portal

I guess I was just hoping for a different answer at this point or some indication that there was some movement on this.

This scenario is pretty clearly provided for by the OAuth 2.0 spec by supporting the client_credential grant type. A Guide To OAuth 2.0 Grants - Alex Bilbie

I find it hard to believe that the answer to server-to-server communications is to have someone from our team remember to manually go in every 9 months and generate a new access/refresh token. Could you imagine if AWS required that to access resources? What happens when (not if, when) someone forgets to go in and generate a new refresh token?

[bradb (Bradley Booth)]

I understand the frustration. We have some technical limitations around using the Client Credentials Grant that we have been working at removing. We have also started work on Personal Access tokens that are scoped to a specific application and user (similar to GitHub). We hope to have some news on this very soon.

Also for the standard Authorization Grant that we use now, you should not have to manually do anything after the first authorization. Not sure where the 9 months is coming from but Access Tokens are good for 24 hrs and the Refresh Token is good for 6 months. When the Access Token is refreshed a new Refresh Token is issued with another 6 month expiration. So if you are refreshing everyday you can go forever without user interaction.

[Scott_Bennett]

Ok. Glad to hear there is plans to support other authentication methods than Authorization Code grant types. Any timeframe around when we might see those?

As far as the Authorization Grant workflow, I just want to be clear, if I use the Refresh Token to generate a new Access Token, are you saying that I will also receive a new Refresh Token with another 6 month expiry? I ask because I wasn’t aware that was how those are supposed to work. My assumption was the Refresh Token was granted once upon initial authorization. If I’m wrong, then yes, we could probably use that as a work around until such time as you guys support additional authentication schemes.

[bradb (Bradley Booth)]

Exactly correct on the refresh token. Refresh tokens are single use, so you will get a new one each time. There personal access tokens is being worked on right now.

[Rob_McCloskey]

Still no way to do a long lived token that is a secret for server to server communication?

Having a stateless component that does work is not possible under the current pattern, unless using the legacy api, which doesn’t have all of the new functions.

[Shahzad_Ali]

Is there any progress on this?
Have you been able to implement OAuth2.0 client_credential grant types?