I want to send data from my website to the REST API but when I just tried to setup a connection it looks like it only accepts oAuth.
Is there a way to just send data to the API using the client_id and client_secret?
The website is just going to create a contact and add tags to a contact so we do not need the users to sign up to oAuth for this to happen.
I’m looking at the XML-RPC docs (xml-rpc - Keap Developer Portal) and it looks like you need to keep refreshing API tokens every day.
How long does the access tokens last?
If the specific code does not run for X days, will it just expire?
Good morning Richard!
A client_id and client_secret are the authentication for the developer, but a given user needs to authorize you to access their data. Doing so through OAuth grants you an expiring token to allow you to manipulate their Infusionsoft data as if you were that user.
Yes, tokens expire. This is a standard mechanism to prevent compromised tokens from having unlimited perpetual access to the data.
You can refresh the token more frequently, if you like, but if you let the token lapse, the user will need to re-authorize you again.
Ok so is there no way that I can do this without having to create a new token every day?
You will need to refresh the token, yes. Most consumers do this with a scheduled task.
This Stack Overflow topic may give some insight into why we implement Access and Refresh Tokens in this manner:
Ok, how long is thee Refresh token valid for?
Here are some links that I found useful when trying to implement application like behaviour (i.e. users not authorising the app) but still using OAuth authentication.
Taken from the above links, the refresh token will expire:
Currently the access token expires every 24 hours which means the refresh should happen every 21 hours
And:
Like the originally granted token, this expires after the amount of time in the expires_in field (in seconds)
The access token is good for 24 hours but the refresh token (last I’ve heard) is good for 90 days. Often this can just be managed in the background with a CRON job or windows service scheduler, which is what is most often done. You can just run the refresh when someone accesses or logs into a system and then that would be possible for 90 days at a time given no access in that period.
Refresh tokens are currently good for 180 days.
My application just needs to send some customer data from my Laravel app to Infusionsoft. It’s not something that people will need to use oauth for, is there no alternative?
If you are just using a script to access your own data, or that of an Infusionsoft Application that your account is linked to, you can generate Access/Refresh Tokens directly from Account Central. You can then persist those and refresh it on a scheduled basis to maintain access.
But what happens after the refresh token expires?
I have to manually reset this all the time? What if somebody forgets to do this and then it will break the application and IS will fail to receive really important information
Hi @Richard_Sanderson, when you refresh an access token you are given a new access and refresh token. The new access token will be good for 24 hours and the refresh token for 180 days. If you store the new refresh token each time you refresh the access token and use it for the next refresh you will be good.
It’s not a case of “people needing oauth”. OAuth is the method of authentication and it’s not based on someone needing it, no different that a user id and password has anything to do with someone needing it. It’s required, regardless of the use of the api. So if you’re creating an application/integration that is meant for only your company’s use, the api getting used to do that would still use oauth. That’s your authentication method.
For a short time longer, you can still use the legacy key method which provides direct SSO (which you can have with oauth by keeping the token refreshed every 24 hour), but the caveat is that it’s not going to be continued in it’s use and at some point that will result in the requirement of oauth anyway so it just makes sense to use what will be around for longer.
I’ve tried to setup the API connection again. I have added a callback URL on my server but when I go to the URL generated by getAuthorizationUrl() it allows me to authorise the infusionsoft app and then just sends me to the account section.
How is this thing supposed to work? Normally oAuth will send the user to the callback URL then the token is stored in the application. Why is IS just sending me to the account section? There’s a way to click onto generate acces and refresh tokens but the people that use the system i’m creating shouldn’t need to do this then add it to the database manually. Why can’t it just send the user back to the callback url?
Is there really not just a simple way to connect to an account using a client ID and secret?
Due to the fact that Infusionsoft ties all apps to one login, there is the extra step of choosing which app is to be authorized. The point you’re getting to then, is to tell oauth what app the authentication is to be for. I shot a video that might explain some of this a bit better.
Hi my oauth flow does not work like in your video. It takes me to the allow/deny page and I get this…
The application ___ by ___ would like the ability to interact with one of your Infusionsoft applications.
Allow ___ access?
There’s only 1 infusionsoft account on this profile so there is no dropdown. I click Allow then it just takes me to the “Your Accounts” section of the Infusionsoft dashboard.
I setup a test application with a callback URL but it just sends me to the accounts dashboard after authorisation.
I want to re-iterate something… This is just an internal PHP code that will send some data to Infusionsoft. No clients or anybody other than us will be using this. This 1 account will be hooked up to the PHP code. Why do we need to setup oAuth for this?
Good morning, @Richard_Sanderson!
I think there are two questions there, “Why use not support simpler mechanisms?” and “Why does Infusionsoft only support OAuth2 going forward?”
In the first case, we did previously support an API Key form of authentication. We found that it had many failings, including inability to segment throttles based on multiple accessing applications (since they were all using the same key) and problems with deauthorization (since every authorized application was using the same key, the only way to remove one was to change the key and update all of them). Additionally, should the API key ever be compromised, either through man-in-the-middle attacks or application owner data breeches, there was not a way to identify bad actors by traffic patterns of a single token owner, and they would maintain access in perpetuity without any indication to the authorizer.
That leads to the second point: Infusionsoft has chosen to only support OAuth2 as our authentication method going forward because it does mitigate the above issues, and so that we have the ability to provide additional protection to the finances and livelihoods of small business owners around the world. It is indeed a more complicated flow than a simple API key, but the exchange is more than worth the additional effort involved, and there are any number of client libraries for various languages that simplify the process.
What is the url you are using to authorize? Something like this…
Your example worked when I clicked authorize.
Here’s my authorize url
