Am I required to implement OAuth?

YES, if you want to access a small business owner’s QuickBooks Online data.

Am I required to implement OpenID?

YES, if you want to offer your app on Apps.com.

Why we have requirements

The short answer: we have them to ensure a consistent customer experience across all apps.

Imagine if the first 10 apps that came out on the iPhone had 10 different experiences to install them. I suspect the Apple App store wouldn’t have been as successful as it is today. Apple set a new standard for the approval of 3rd party apps. They even told the following to Intuit when we started building iOS apps, I think the quote. during a meeting with them, went something like this: “They are Apple customers first, and Intuit customers second.” This vision allowed Apple to have extremely rigid requirements which ensured a consistent and high quality experience across all developer’s apps. The rest is history.

In a way, we have taken this same approach to our requirements. QuickBooks users deserve to have a consistent connect and sign-up experience across all the small business SaaS apps that they connect to their QuickBooks data. Not only do they deserve it, in fact they demand it.

During feedback sessions with small business owners, they repeatedly viewed 3rd party apps in 2 ways: 1) many just assume 100% of the apps are made by Intuit, so they should work, and not mess things up 2) those that understand that they are 3rd party apps, but looked at Intuit as the party that should ensure the 3rd party apps worked and not mess things up.

Just over two years ago, my focus was on the customer experience for Apps.com apps. I worked very closely with the very first app developers to improve the user experience in their app, as well as the experience on Apps.com. The requirements we have today are a result of many usability tests, customer feedback, and a lot of adjusting over the last 3 years years.

Stop re-inventing the wheel, and use best practices.

Early in the days of the QuickBooks Online REST API and Apps.com, Roger Neel, the founder of Mavenlink, and I were discussing his QuickBooks integration and he asked, “Which apps should I be modeling my app after, what are some of the best practices?”

To which I responded, “You are going to be it, we are figuring this out together.”

Roger never had the luxury of our current app developers, he couldn’t steal anyone’s best practices. Developers in today’s world can go to Apps.com and try some of the top apps and steal from the best. As I said in a previous post (Using a two phased approach to launching on Intuit Apps.com) I highly recommend that all developers try out some of the top Apps.com apps before creating their own QuickBooks Online integration.

Here are some scenarios that may fit your situation along with an app that is nailing it.

• Cleanest implementation of the Connect to QuickBooks button: FG Receivables Manager
• OpenID on Sign In page and management inside of an app: Mavenlink
• OpenID implementation for sub-domains with individual Sign In pages: TSheets
• Apps.com sign up and first use workflow: ZenPayroll  (now Gusto) and FG Receivables Manager
• Apps.com One Click signup experience for a high-touch sign up workflow: TBD
  
• Detection of an already existing account when an new Apps.com sign up occurs: TSheets
  and Mavenlink
• Good model of how to list multiple integrations (especially if you charge for each integration): Jobber
• An mobile app using en embedded browser to do OAuth: InvoiceASAP

I will also be following this post with three more posts in the next few days:

• Connect to QuickBooks (OAuth) Dos and Don’ts
• Sign in with Intuit (OpenID) Dos and Don’ts
• Apps.com sign up Dos and Don’ts

-david