I do a lot of freelancing work to build up my small side business. A job I recently took on was to integrate an ecommerce site into Quickbooks using the Quickbooks Web Connector.

If you've ever had to use this software, I'm sorry. It is not friendly. You essentially have to write your own SOAP server that is called by Quickbooks.

Then you have to send them XML in their QBXML format (of which, the documentation only really works in IE, kind of works in Firefox, and not at all in Chrome -- that's right, just reading the documentation requires a specific browser). Debugging is a pain.

So I thought a service that abstracts that would be a good idea. We would provide the Quickbooks WebConnector file to you, you install it, and then start sending your invoice information to a nice RESTful API.

We handle the rest and ensure your data gets into Quickbooks properly. If you're interested in something like this, please subscribe to the mailing list.

PS. I'm doing the same for the Google AdWords API, which is also not a joy to use -- http://metricsapi.com/tour/google-adwords-rest-api

I'll look at this later, but I used Consolibyte's open source QuickBooks PHP DevKit[1] for a recent client project.

This is not a trivial process, but I didn't have to write my own SOAP server.

[1] http://consolibyte.com/quickbooks-open-source/

I used the same kit a couple of years ago: once I realised that I just needed to give it a database so that it could manage its own state and let it do its thing, it was generally a breeze.

At the time, at least, there was some weirdness with integrating with the Canadian version, however. Nothing I couldn't resolve generally, and it may very well not be a problem at all anymore.

But yes, '+1' for the QB PHP DevKit.

Interesting idea. I don't use quickbooks, but I liked your take on the google adwards. I recently tried to look at pulling data from Analytics, and the Google API just seemed hugely and unnecessarily complex.

Trusting a single vendor gateway however seems a little risky. As a developer I would much rather have a (open source) wrapper library I can use instead of introducing another layer/potential point of failure. That said, if you want to keep this language-agnostic, you'd have to run a REST gateway of some sort anyway, so having a service provider to handle this for you can be an advantage.

Why not just use the Intuit Anywhere platform?

That's not a bad idea, however the customer wished to use Quickbooks WebConnector because that is what their Quickbooks consulting agency recommended.

That may be the case, but what you are proposing is already addressed by the Intuit Anywhere Platform. You can use their APIs to import customer, invoice, product data, etc. And it supports both QB desktop and QB Online.

It doesn't really solve the same problem.

IAP allows SaaS providers to provide their "App" via the quickbooks "App Store". That is great if your a SaaS provider, someone like Freshbooks.

What IAP doesn't allow is using its APIs via your own custom in house application that you don't plan to publish on their "App store". If your using QB desktop your only real option is web connector hell.

> What IAP doesn't allow is using its APIs via your own custom in house application that you don't plan to publish on their "App store".

You don't have to publish on their app store.

I actually did something similar for the National Weather Service API. Not as bad as Quickbooks though.

I'm very excited about your idea. I've worked with some of their APIs and they are definitely lacking.

We built an in house solution for communicating with quickbooks. We implemented the soap service and communicate with it via a message queue. The biggest issue we've run into is that the web connector is polling the soap service, so you can wait as long as 1 minute for a response depending on how often the web connector is set to poll. We implemented a work around that forces the web connector to poll more often, but when it is in this "synchronous" mode, the quickbooks file is held open and cannot be closed. I am curious how your api gets around this? If you have a good solution, I think we'd definitely be interested in using your api.

i've worked with web connector before, though not extensively. we did invoice and customer imports. no extensive sync or anything. the key is just to write against their giant xsd schemas that are in the install or support folder. also this exists: https://idnforums.intuit.com/messageview.aspx?catid=56&t...

Yup, and none of that is any fun. As a developer, what would you prefer: writing against their giant XSD schemas or just making a POST request to a URL with invoice information? I'll take REST any day of the week.