Two different API docs confusion

There is this:

and this:

Both have different calls. One can list products, one can’t. One can create transactions, one can’t.

Is one current and one out-dated? Which one is correct?

The XML-RPC API is our legacy interface, and will someday be depreciated in favor of the REST API, which we are currently adding additional functionality and endpoints to.

So you can only interact through curl? No php? Also in the REST API, I cannot currently post an order transaction? Is that correct? And, can I retrieve a Contact by email?

Hi @Brittany_Jacobs, you can certainly interact with the API via curl but our php sdk supports both REST and XML-RPC.

You’re correct that you can only place orders via XML-RPC at the moment. You can find a contact by email using the REST contact endpoint using the email filter parameter. Please note that this is an exact match filter.

Tom, you say “someday” – we’re in that strange netherworld where the functionality we need is only available in XMP, not REST. We’d really rather not go down that road but there’s no other way.
What’s the potential deprecation timeline for XML? It sounds like some vague way-down-there date that only the CTO might know, and not even then.


Not so sure the CTO/CEO/COO or any other actually ‘knows’ when right now. This has been talked about for over three years now (just to give a point of reference). I do believe it will happen but not real soon. The way we have prepared for this is by compartmentalizing code for authorization. It will then only require changing a single function to manage.

I hope the transition should be easy and smooth, i have lots projects using legacy API key and now exploring REST and access token to do the same tasks which im doing with legacy api key

Yup, same problem every dev is seeing (how to make that transition without negatively impacting their clients). IS is exploring ways to make this as simple and straight forward as possible though. I don’t know what they’ll decide on as an option but they are working on it.

1 Like

I’m also interested in how this plays out with the transition. I’m currently building an application for a client and I’m attempting to use the REST API to make the application more future proof, but there are some significant limitations in the REST API (in my specific case I need a way to pull a list of contacts who have a certain tag, and get custom field data) and I’m not sure I’m going to be able to finish the project on top of the new API.

My question is whether there is a timeline for how quickly the REST API development will be progressing, if I should expect functionality to be coming rapidly or to not hold my breath for anything significant to change over the next few months. The answer is likely similar to the question of when the legacy API will be deprecated, but I wanted to give it a shot.

The only real concern any should have is the authentication method. What will be sunset will be the api key method for authentication. The iSDK have been reworked to use OAuth and anything built using that will still work. REST is the newest offering but it’s not the only thing that will remain. As long as you are using OAuth and not the api key method you can rest easy.

Awesome, this is the best news I could have heard!

OAuth is a little trickier to work with than the simple API key method, but transitioning an app to a different authentication system is on a different level of magnitude than migrating from XML-RPC to REST and so that’s great to hear that the XML-RPC API isn’t going anywhere.

It might be worth putting a comment on the XML-RPC docs (xml-rpc - Keap Developer Portal) that the authentication method will be deprecated at some point but not the API. It would clarify a little bit, since the word “Legacy” that has been plastered on everything XML-RPC gives the impression that the API itself will be deprecated at some point.

Understood, and I agree…it does leave some to the imagination lol It used to be that Legacy meant just the iSDK using the api key method but then (anticipating some of the developer concerns like what you have mentioned) some got together and converted it so that OAuth was possible with it too. REST is definitely the preferred method and IS is certainly looking to steer everyone in that direction but OAuth is the biggest of their sticking points.