We just launched this and I can answer questions if anyone is interested.
MajorApi is a RESTful wrapper around QuickBooks. QuickBooks is notoriously difficult to work with. Yes, they do have some REST APIs you can use with their IPP platform, but for developers making custom QuickBooks integrations you're almost stuck using WebConnector.
WebConnector requires you to write your own SOAP server which is not fun. We've written a nice REST service on top of this, so all you have to do is download the WebConnector software from QuickBooks and install the .qwc file we provide, and you can start sending customers and invoices to QuickBooks in under 5 minutes.
Let us know if you have further questions. Thanks!
As a developer and Texas-licensed CPA, this makes me so giddy. Is there an API for logging time yet? I'm working on a web app in that space and would love REST integration instead of a csv middleman
No time logging yet. We focused on what we perceived were the two biggest use cases: customers and invoices. Prioritizing our integrations next, we'll look into time clocking.
How are you recommending deployment of MajorApi for applications needing to read from Quickbooks? I've written a Quickbooks integration web service using the desktop SDK, not web connector, and ultimately we had to abandon any reads from Quickbooks in favor of essentially mirroring the data in a SQL database. Can the combination of MajorApi and web connector handle real-time QB reads under moderate load?
Right now when you create a new MajorApi QuickBooks Application, it reads in your items and sales reps so they can be references in invoices you create.
Then we have a database in the middle of the two because you can't have real time reads from QuickBooks with the WebConnector.
Edit: So to answer your question, there's no such thing as real time reads using the WebConnector. You have to send an XML query to QuickBooks which returns the data. We plan on integrating with QuickBooks online soon which will allow real time reads.
I (and I'm sure many others) wrote something ugly in this space years ago in php and have spent much time since attempting to drown the remaining relevant neurons in whiskey. Good luck!
There's also Levion - we don't have a documented API but we use Ruby on Rails that has JSON and XML out of the box. If there are interested users of our API, we would like to hear from you. Send me a shout at jason at levion c o m
This would make my life much easier, glad your tackling it.
Any idea where Vendors and Bills are on the priority list to add to the API? Our business model is similar to a consignment transaction so every time I generate an Invoice to a customer I also need to generate one or more bills to vendors.
I don't know yet. There's so many different working parts of QuickBooks it's tough to determine where to prioritize. Some of our initial customers use vendors extensively, so they're a bit higher on the list.
Oh, believe me I know. The JaxB XML mappings for the QBWC api in my project are are 302,976 lines of code in 1122 files. Its auto-generated of course but still creates a messy with permgen space. I'd love to dump it all for a REST api only using what I need.
This looks excellent! And stunned to see that Quickbooks is the first one being tackled here. I just recently started rolling my own API to QuickBooks Web Connector. It's Coldfusion backed and assembling and parsing the SOAP XML going back and forth. It's pretty miserable.
However, there's no way my company is going to authorize or financial data flowing through an intermediary 3rd party.
How many different countries has this been tested with? I assume it's mainly targeted at US, but what about CA or AU?
I can understand why the AU may be harder to do, but as far as CA is concerned I remember having quite a few problems using the Intuit PHP SDK so just curious if that is supported or not?
As long as the QuickBooks WebConnector software can run with your QuickBooks installation, you should be good to go, we're not restricting it to any specific countries.
OK, but it hasn't specifically been tested with Canadian builds, for example, right? I get that in theory this should work but like I say, when I was using the PHP SDK there was definitely some interesting 'issues' (I believe tax rates for one). Was just curious if this was tested at all.
I'm glad to see some developments in this area, that's for sure.
17 comments
[ 8.6 ms ] story [ 50.7 ms ] threadMajorApi is a RESTful wrapper around QuickBooks. QuickBooks is notoriously difficult to work with. Yes, they do have some REST APIs you can use with their IPP platform, but for developers making custom QuickBooks integrations you're almost stuck using WebConnector.
WebConnector requires you to write your own SOAP server which is not fun. We've written a nice REST service on top of this, so all you have to do is download the WebConnector software from QuickBooks and install the .qwc file we provide, and you can start sending customers and invoices to QuickBooks in under 5 minutes.
Let us know if you have further questions. Thanks!
Then we have a database in the middle of the two because you can't have real time reads from QuickBooks with the WebConnector.
Edit: So to answer your question, there's no such thing as real time reads using the WebConnector. You have to send an XML query to QuickBooks which returns the data. We plan on integrating with QuickBooks online soon which will allow real time reads.
Any idea where Vendors and Bills are on the priority list to add to the API? Our business model is similar to a consignment transaction so every time I generate an Invoice to a customer I also need to generate one or more bills to vendors.
However, there's no way my company is going to authorize or financial data flowing through an intermediary 3rd party.
Is there any other solution?
I can understand why the AU may be harder to do, but as far as CA is concerned I remember having quite a few problems using the Intuit PHP SDK so just curious if that is supported or not?
I'm glad to see some developments in this area, that's for sure.