Has anyone been having trouble with the XML-RPC version of the API lately? I have many old scripts that access the API with the old method, and they have been running fine for years, but the last week or two, all commands have been very slow. For example it takes 8-10 seconds just to do a connect. I thought I might be throttled for some reason. I’m still waiting for Infusionsoft support to verify that. If I do a basic script that includes a connect and 2-4 calls to the API it will tend to time out. Sure, I can increase my timeout value, but there is no way these scripts should be taking over a minute to run. Am I alone in experiencing this problem? By the way, I tested from 3 different servers (entirely different providers) and experienced the same result so it is not a local network problem.
Checking a few accounts my side, I am not experiencing any delays.
I have not heard of any problems mentioned recently.
Are you getting the same problems now?
Thanks for your response Pav. It is somewhat intermittent, but happens about 80% of the time. After waiting 3 days for advanced support they responded with a link to a FAQ that did not address my question at all. Typical example of support “punting” when they don’t have a quick and easy answer
I think I might be experiencing a similar problem with an integration that I “inherited” recently. It’s been coasting along fine for a few years, and now we are suddenly seeing problems with the performance. Have you made any progress on this issue since your post? Thanks in advance!
I could not get support to take me seriously at all. They just acted like
I was being throttled, but I was not getting a throttling message in the
logs and I should have been nowhere near the transaction limit. I think it
is something on their end, but it is intermittent. At the moment my
performance is ok, but I expect it to to get bad again in the future and I
have no idea what I can do to fix it. I suggest you open a ticket with
support. If enough of us report the same problem they may have to actually
put a developer on it to look at the logs on their end and see what is
going on. I’ll reply to this thread if there is any update on my end.
You indicate that these are old scripts but are saying you’re not getting a throttling message. That would be because there is no throttling message available or sent with the sdk.
I am pretty sure I have seen a throttling message a couple years ago, when
I was trying to update every contact via the api. It was too much too
fast, and I saw throttling error messages come back. Also the
documentation on this page states there is a throttling message when using
the legacy API key.
There has never, at any time, been a throttling message with the sdk. The mechanism just doesn’t exist. The link you shared is for OAuth, not the api key use.
However, I see why it sounds that way. They’re not giving throttling as they are defaulting to the lock out caused by pool depletion. But ok, so you don’t see a message about throttling. Have you tried to profile calls for timing to see if it’s the api server or something else?
Thanks John. That is interesting what you say about throttling message. I
may be remembering wrong but I could have sworn I saw something in my logs
that looked like an error message regarding throttling or hitting a limit
or something. Also if you are correct the page that I linked to needs to
be updated because it seems to state very clearly the exact error message
you can expect to see if you hit your token limit - I can’t see any other
way to interpret it.
I am interested in your suggestion to profile calls for timing. Can you
elaborate on how that would be done? What I did was create a simple script
that only did a connect statement to the api and ran that and it took 8-10
seconds to complete. This was during a time when server load was low and I
saw no latency or connection problems to anything else. I know that’s not
very scientific so if you can guide me to a more rigorous test I would
welcome your advice.
The page you linked to has throttling info for both OAuth and the Legacy Api Key. The server will respond witht he provided message for legacy api key access. I am unfamiliar with the PHP SDK and whether or not it bubbles that up. Using OAuth however you will get a different http response code and relevant headers giving the limits and what you are currently at. In fact the limit information is returned on every request regardless if you are throttled.
That’s exactly what has been said. The iSDK does NOT report throttling, just a general exception. He is using the iSDK if his scripts are using “…the API with the old method…” then all the other things you’re mentioning do not apply.
I want to get this resolved however I don’t want your information to be posted publicly. Please create an API support case here: https://developer.infusionsoft.com/support/tickets/create/
Right now this case will come directly to me and I can look at it. Please include the Infusionsoft application name that is being used so I can look into this quicker. Throttling is something that we want to make sure to help with as it can stop or in this case slow a business down (which in some cases is just as bad as stopping the business).
While we would like to see everyone move to oAuth we also understand that it will take development work and we haven’t set a sunset date for the Legacy Authentication Method at this time. Let’s see what we can do about this slowness.
@JonSmith, personally I think you should abandon the OAuth route completely.
OAuth does not improve things, it actually makes things worse for developers.
Converting from Legacy to OAuth is more problematic, and not every development scenario has been covered in OAuth either.
The OAuth implementation needs significant improvements if its going to succeed.
Our plan is to support the use of OAuth going forward, and new offerings from Infusionsoft will use it exclusively. We will continue to support Legacy API Keys on the Current Builder Series product for now, but developers who wish to future-proof their applications should look to utilizing OAuth rather than developing around a legacy access mechanism.
Feature additions for edge-cases around utilizing OAuth are definitely “On The Table” for our partner-focused teams.
Personal opinion alert
So personally, I would dis-agree with the fact that OAuth is worse for developers. Most developers welcome anything that can offer greater controls and metrics to their process. I do agree, however, that there are a number of valid concerns that have filled the developer community and I would break them down into two basic categories. More work or effort for the developer and the potential for a bad experience for the end user. As to the first, all I can say is that while it’s unfamiliar territory for some or just inconvenient for others, that is not a reasoning that decisions should be made by. We take on what is complicated to make it simple for those that can’t or don’t know how. As to the end user experience, this still falls on developers in the sense that we can develop high level plans to solve for that experience on the low level that we are accustom to working with.
OAuth is a good thing. Understanding OAuth, what it is but especially what it isn’t seems to be the dis-connect. I fought with this for months and finally had the break through that made this one fact clear. OAuth is not an authentication protocol. Sounds like a small distinction but it made an entire difference in understanding it. The benefits are that all we have asked for in the past with the api key method is provided or at least available with OAuth. It’s time to just buckle down and learn how to make it work in a way that is easy for the end user. Much of this has already been accomplished. The big issue that remains is token management. There are a number options there but there really hasn’t been much effort to pursue them…just complaints…
Again, just my opinion or 2 cents worth but I think it’s always more productive to pursue solutions than keep chasing after problems.
Well said @John_Borelli. I agree wholeheartedly. I would also like to add to what @TomScott is alluding to. Our team is working hard to make developers’ lives easier. That is our sole purpose. We want to serve our developers and partners so they can serve our customers and make Infusionsoft even better. We have discussed ways in which we could off load token management from you guys, but are in the early stages of figuring out if we can pull that off in a secure way. This could be SDK based, proxy endpoints to handle renewing for you etc. All options are on the table. In the meantime we are working on tooling to make OAuth accomplish similar goals that the legacy key excels at: ease of use, no need to for a UI to redirect to after authorization, etc. We hear you guys and we are working hard to make all aspects better.