For those of you interested in such things.
It can be headless or front-ended using readline.
Hi Jeffrey,
Just sharing my thoughts on what you have raised here.
I would say that the majority of the API development would be PHP Language based.
I have seen other developers mentioning they use Node JS, Python, C#, etc, but very few people or none would answer their questions.
I think you would get better response from the Keap API Facebook Community.
Hope that helps.
It is funny that you mention about the XML-RPC. I just recently tested an integration against PHP v8.2.
It is uses a modified version of the Legacy Infusionsoft SDK against the latest version of the XML-RPC Library.
I would say that PHP is not perfect. But each new version does have improvements and they remove the old / bad things, so over time it does get better.
I am not going to go into a PHP debate with you. 
This is the XML-RPC library that I use: GitHub - gggeek/phpxmlrpc: A php library for building xmlrpc clients and servers
It does a good job in keeping backwards compatibility when it releases new versions.
If you want to know, I am sticking with XML-RPC API, as the REST API falls short in a number of areas.
Whoever designed the REST API were either completely clueless in seeing what functionality the XML-RPC API provides, or they were hoping that cutting back on things would not make a difference. I cannot fully convert my integrations into REST API due to the missing functionality.
You will find multiple forum posts over the years with developers asking to do this or that in the REST API, but were told to use the XML-RPC API to get around the problem.
But, Keap master plan is to make REST v2 of the API that will cover all these shortfalls. It was initially released a few years ago that cover a small number of items. Over the years you see the Team keep saying we will add into the future release, etc. They are not actively working on the API, because there has been a lack of progress.
As for Artificial Intelligence, OpenAPI, or anything else in Keap, good luck in seeing that any time soon. Keap are very slow in keeping up with the changing world. They were slow in supporting Google Chrome, they were slow in supporting Stripe. and would be slow in anything else. There is hardly any progress being made in the Keap Max Classic Platform as well.
They are not bothering answering the Community Forum Posts lately as well.
@Pav Just a little history and update with the API efforts. Being one of the clueless developers for v1 I can give some background
- Work on v1 was deprioritized and the API Team was dissolved. There was an original plan to have parity with XML/RPC within reason.
- A few years ago we able to prioritize API work again and we decided to create v2 instead of working on v1, due to our experience with some performance issues we have with v1 and XML/RPC, specifically paging. It was something we needed to correct, but was a breaking change. We released a few endpoints on v2, but again API work was deprioritized.
- We are now working heavily on v2, due to a huge buy in from our current Product owners. Expect to see many additions to v2 in the coming months. Every development team is dedicating time to v2 for the next few months.
- The plan for v2 is XML/RPC parity (with a few exceptions), and exposing many additional resources that are currently not available via XML/RPC nor v1. My team and I have been pushing for an API first development philosophy for a very long time, and we are starting to see progress towards that. I am hopeful.
- Our long term goal is (and always has been) to get rid of XML/RPC.
I hope this will give you some faith that we are moving the APIs forward. I am definitely excited. If you have any questions I would love to answer them.
1 Like
@Jeffrey_Chimene I was responding to @Pav. As far as Open API goes for v1. There is no development happening on v1 so not sure what there is to discuss. All of our specs for both v1 and v2 are autogenerated, so we don’t control too much about them. The long term plan around Open API is for the ability to autogenerate SDKs via things like Swagger Codegen.
@bradb, thank you in giving an explanation of things.
I need to say that Keap has made a big mess with the API since REST was introduced. I understand you need to make progress and us developers were hoping that it would give us additional functionality, but not also have gaps in the functionality in comparison to XML-RPC.
If REST v1 was say 95% compatible with the XML-RPC functionality, then more likely we would have moved to REST and you would have decommissioned the XML-RPC by now. It is a shame that the original plan was ditched.
You have seen over the years developers asking questions like “How can we do this in the REST API?”, and the answers have been “You cannot, but the XML-RPC API can”, or “We will add this functionality in REST v2”. But REST v2 was initially released a few years ago, and look like it had been abandoned.
This has now caused the developers to use the API in the following ways below.
- XML-RPC
- REST v1
- REST v2
- REST v1 / REST v2
- XML-RPC / REST v1
- XML-RPC / REST v2
- XML-RPC / REST v1 / REST v2
It is good to see that you are now working away on the API again, but it should not been deprioritized as it has now caused knock on effects. If REST v2 becomes as good as the XML-RPC then developers can move across and use it. But the XML-RPC API has been around since 2006 (?), and there is going to be a lot of integrations that are still using it. So terminating the XML-RPC API will take few years to do.
Anyway, let us see how things are by the end of year. 
@Jeffrey_Chimene, yes I have seen you a few years ago in the forums as well.
@Pav totally agree on priorities and the convoluted usages between all the APIs. I have been working hard to evangelize the value of APIs and an API first mentality. I am just not the decision maker on the priorities, and all I can do is try to persuade as much as I can.
1 Like