Why does the XML-RPC API not always pass back XML?

API Q&A
1

I’m trying to get the XML-RPC API to work for me, and I’m running into an error. Unfortunately, I don’t know what the error is, because instead of being handed back and XML error, I’m getting html passed back.

This is an example of that happening

https://api.infusionsoft.com/crm/xmlrpc/v1?access_token=28zsn2b9v6

That is a fake token - it gives back

Developer Inactive

Now, when I get an h1 back instead of an XML object, the npm library xmlrpc which is what I am using just throws an error:

Error: Unknown XML-RPC tag ‘H1’

So I can’t actually see what the error is.

I know that the access_token I’m using is good, as I use it in a REST request immediately proceeding this and that is going through, so Inactive Developer doesn’t make sense. What are the other possible errors that return non-xml responses?

Here is a link to the more geeky version of this question with code / etc on Stack Overflow. Any help is appreciated!

https://stackoverflow.com/questions/48017442/xml-rpc-responds-with-html-instead-of-xml-on-some-errors-how-do-i-see-the-html

2

My guess is that the Node XML RPC library is not handing the query string properly. You can add the access token to an authorization bearer header which is actually preferred. So change you code to look more like this:

const headers = {'Authorization', 'Bearer ' + token};
const client = xmlrpc.createSecureClient({'url': 'https://api.infusionsoft.com/crm/xmlrpc/v1', 'headers': headers})

I am no node expert and this is just from taking a quick look at the nodejs xmlrpc library. Hopefully it will work for you, but the error you are getting is for sure caused by a bad or missing access token.

3

I actually sent a pull request to the node-xmlrpc people to fix the query string issue-- with updated tests no less. No word from them about it yet. The dev seems MIA.

node-xmlrpc should at least give some mechanism to retrieve the actual contents of an HTML page returned in this way, because it is something that can conceivably happen no matter how well-designed an xmlrpc server is. But they don’t.

It seems to me that the html-type error pages you get in this way must come from a reverse proxy that’s not aware it’s talking to an xmlrpc client. It’d be very helpful if you could configure them to somehow return an error that xmlrpc can interpret for those paths (might be a little late now seeing as the XMLRPC library itself seems to be on its way out-- good riddance if I’m being honest. Bring on REST!)

4

I will look into what options we have available at the reverse proxy to spit out a xmlrpc compliant error message. It might be a breaking change since some people might be relying on the html right now :slight_smile: