It is essential for our integrated product to have API access to tracking categories for more comprehensive reporting. A large number of our customers are interested in Xero and would be far more keen on Xero if they could report on their tracking categories.

Essential for running our business intelligence reports that integrate all of our systems.

This is really a no brainer, I don't think I've ever come across an API that can't do everything the GUI can bar 1 or 2 items. The level of integration that a full API allows for is key for uptake and growth. That is of course if xero want's an ecosystem

As an IT company looking to use Xero.com as our accounting package, we regard it as a big decision to change and access to all our data via an API is a big point for us. We'll be looking to make a change by June if we go through with it, so we'll be watching this issue with interest

We would like to see tax information (TaxNumber, AccountsReceivableTaxType, AccountsPayableTaxType) included when retrieving Contact records.

>>So what are the burning features that you believe will make your integration better? Or the features that are lacking for you to even start? How do we start to make this better for you guys?

Yes features are lacking that we cannot even start. The API is very limited.

Why not start on something core like Invoices. Now, fully expose ALL invoice functions available in the UI. Then move on to Contacts, rinse, repeat.

If that does not work for you then find some other order where at the end of it everything is exposed via the API.

For me, I'd like to be able to create approved invoices, enter line items, get invoice PDFs, and receive contact accounts status such as unpaid bills, outstanding amounts etc.

For me the major features that I'm interested in are:
1. Being able to retrieve the exchange rate that Xero is going to use when converting the price list items back to my currency (so that I can use the same price when calculating the alt-currency amount) - this would be a nice easy-win and would allow us to simulate currency-aware price list items.
2. Being able to define price list items through the API - we are reselling products that have a complex pricing structure, so creating price-list items manually is time-consuming, lord knows what we will do if/when our suppliers update their pricing structures (we can handle it easily on this end, but having to manually enter the price-list-items is a real pain)

This is an excellent discussion but there are lots of points made here so I'll try to address the ones that seem the most pertinent.

First of all - we do have a dedicated team and our public API is key to our goal of becoming the accounting engine for the cloud. Our CEO recently blogged about this strategy (http://blog.xero.com/2010/08/best-of-breed-v-all-in-one/). If we're going to integrate with best of breed applications then we need to have the API to cope with that. For example, every product feature discussion includes how the API is affected or how the API should work. Obviously everyone has feature requests for the API and our team are working on them. To be honest we also have deal with the general resource juggling that any start-up has to do so sometimes the API release cycle slows down more than we'd want it too - but it's not a second-class citizen even if it appears that way.

Which nicely leads into the architectural discussion regarding how we should build our app. While it seems like the ideal design for a fledging API is to build it completely open and make the web app a consumer of it, we needed to make architectural decisions around usability, performance, security, maintainability and speed to market which meant it wasn't feasible for us to design the Xero development framework in this way. We've definitely litigated this decision in retrospect, and over time we've moved to a more loosely coupled architecture internally that utilizes more internal web services. However opening these up is not feasible for lots of reasons (the non-functional ones above being the chief of them). Our internal API is very complex - our design team has done a great job of making the complicated simple in the UI, but the complexity still exists - it just exists in the back-end where it belongs.

When we made those initial architectural decisions we made them with a public API in mind. It was on the first feature roadmap - it's been a goal from day 1. But the best way we saw to do this was to provide a restful API that exposes what is essentially a programmable user interface. Simplicity, security & performance are all key. Even though we expose some of our schema to developers there is still a lot that's going on behind the scenes - all that's missing with our public API is the pretty UI that we've developed for our customers, so that you can provide one to yours while still accessing our accounting engine.

So coming back to the basic question will we expose everything via the API? Absolutely. But it won't happen overnight. Even if we had the entire team working on it we'd still need a feature roadmap to work towards. So what are the burning features that you believe will make your integration better? Or the features that are lacking for you to even start? How do we start to make this better for you guys?

Craig
CTO

@chris: We are also struggling with the canned responses - these guys just don't seem to want to listen to the problems that their customers are having and seem to prefer devoting time to deflecting them rather than dealing with them.

The API is severely lacking - for an online system not to have a comprehensive API is worrying. It's going to massively slow down integration with internal systems, and third party systems. Such integration is vital for your customers - if we can't integrate properly, we are forced to go use systems that can integrate better even if we would prefer to use Xero. Financial stuff is the hub of any business - not being able to integrate with a hub makes the hub pretty useless. I've seen Xero's response to buzzware and it worries me a great deal - you need to set up a dedicated team working on the API IMHO. Providing a list of reasons why you won't work on the API isn't the right approach.

I think you are getting some good advice here on how to architect your UI and web services. We are looking for a Quickbooks Online replacement, but we need tight integration with our BPM processes. With so little exposed through the current API, we unfortunately have to pass on Xero.

@owen ... if you re-read the original request, the idea is to make the API your core application and your UI a client to that API ... by doing this you don't need to devote ANY developer time to maintaining the API, thus freeing up your coders to work on more productive tasks ;)

just entering invoices and customer info is not really useful in anything other than a very small business really. We have journal movements for every customer (of which there are thousands) with different revenue streams and they all need to be tracked and correctly attributed. Right now Xero does not offer the ability to allow us to actually use it.

hi @buzzware. My point is not that we won't work towards making Xero functions available as a whole, just that we have to prioritise work and saying that people want everything doesn't help us to order and prioritise the individual parts... Xero has taken us 3 years to build as it currently stands and we're adding new functionality all the time so the API will inevitably be playing catch up to the core web app.

My point being that this doesn't help us decide if we need to devote our time to getting Manual Journals online vs Expense Claims first for example.... of course you're welcome to wait until everything is available via the API but it isn't something we can undertake overnight.

Many thanks for your comments though and we do appreciate how much people want to be able to interact with Xero via the API.

Owen

Hello Owenevans. I'm a developer and user of another online accounting system considering moving to xero. I also have an idea for a mobile or desktop app that could interface with Xero. Your response above is puzzling and disappointing. This is the highest voted for feature, votes represent what users want. You are effectively saying "Please stop telling us what you want, we'll give you what we want to give you". As you have already solved the authentication and some of the API, it can't be that hard to expose the rest. SEOJoe said it well that you can't predict what developers might come up with, that will ultimately benefit Xero.

please be aware that leaving votes against this request is actually not very helpful for us. We appreciate that people want the whole of Xero exposed via the API but we have to prioritise where our work is undertaken. We would rather prioritise which pieces of Xero functionality we expose with each release.

I cannot agree more with the above statements, that this is the simple biggest limitation preventing Xero from progressing. The current set of v2 APIs seem to be focused on applications Xero is aware of that benefits Xero directly - CRM, Invoicing. Basic function such as reading a trial balance appears to be limited, not on road map or requested in many micro user voice that request subsets of this request - Get everything available via API --- Xero may find applications unconceived that move it to the next level!

Hi. I'm not sure how to explain this, but I really need to read information in Xero. We are in Latin America, in this part of the world we use a lot of print stuff. For legal purposes we print invoices in special formats, functionality that Xero doesn't provide so I have to import invoices and send to print in a custom format. But I need the same for Cheques, belive it or not, we print cheques and I must adjust the format to fit the template. The same is for journals and a lot of other reports that Xero doesn't provide. So I need a very powerful reporting tool inside Xero or just expose everything so I can get the information a made the reports a forms as our distinct locations need.

That would be a perfect world... of course I agree! :)

I could not agree more with Sam's suggestions to architect your site so that everything in the web interface leverages your API thus making everything available via API.