Hi,
I am new to Infusionsoft. I have already build a Ecommerce Portal using PHP & Trying infusionsoft to Automate Marketing Process.
I am trying to find information about PHP API that can allow me to add / update contact without oAuth mechanism as Some logical part needs to be calculated via CronJobs.
Any help / suggestion would be helpful.
Regards,
Anoop Pete
You can generate a token manually if necessary, and then set the cron job to refresh it intermittently. So long as it doesn’t expire and you store it locally, you should never have an issue.
OAuth provides several significant security enhancements, and we intend to eventually sunset Legacy API Keys. I would not suggest building new functionality around them at this time.
This is the crossroad that many developers are facing. That where what we desire in simplicity meets with the requirements of what we have to work with. It would not be good to get stuck on avoiding OAuth because, eventually, it will leave you in a position of having to work it out in a much shorter period of time. As mentioned, managing a database entry for updating active access tokens and refresh tokens is the primary recommendation. I have a video that covers some of the specifics and it might be helpful in overcoming that hurdle:
This is LAME! OAuth is supposed to be used only for direct user interaction. We need to be able to call the api anytime we need via our own member interaction without an Infusionsoft user needing to be there.
Refreshing OAuth token on an interval is NOT a great solution and is very prone to issues. Also it’s just giving us more work!
Why do you believe it is prone to issues and not a good solution?
At Infusionsoft we are expected to provide secure storage for confidential data to our end users, while also providing third-party access to data at an end-user’s explicit request. When you build an integration with the Infusionsoft API, you are acting at the behest of a user to access that user’s application data, and the OAuth token represents that authority. You only need to be granted it once; you can refresh it as needed within the window to prevent it from becoming stale, via cron, via session initialization or any number of other methods. The window for refreshing is currently six months, although we recommend you do so to protect your users on a much more frequent basis.
Does it require a few extra steps to implement? Definitely. We’re working to minimize the impact of that, and have plans for ways to improve authentication to ease consumers through it. Recent changes to Account Central have already made it much, much easier to get a token for personal use if required. Things like refreshing can be a hassle to set up, but it also prevents third-parties who gain access to the token from having unlimited lifetime access to the user’s data.
Does it provide benefits and security that far outweigh it’s costs? Absolutely. We are dedicated to making the platform reliable and secure so that your clients data is protected.
OAuth enables this by allowing an explicit, individually revokable grant to a particular API consumer for a particular user’s application data, whereas a single token for each application is neither secure (since it is shared among all consumers), individually revokable (since resetting it prevents all integrations from accessing data to that application) or tracable (since all consumers access via the same key).
Assuming, a user has gone through the process of getting a valid access_token (and refresh_token), but the application owner would for some reason like to revoke the user’s access while the access_token is still supposed to be valid (24 hours from being issued) -
Thanks in advance!
Only the user that approved the access can revoke. The user can go to their Manage Accounts page (Account Central) and revoke their approval. When that happens the API calls will start to fail with error with a 401 response code and the previously issued refresh token will also become invalid. There is no endpoint to revoke access tokens.
To be clear application owners can only revoke access that their user granted, not approvals that other users in their application granted.