Intuit Partner Platform team blog

Guidance on managing your customer attrition and billing

We are sharing some guidance here to make sure you don't incur unnecessary overhead fees when you have customer attrition. As a reminder, Intuit charges developers $5.00 per month for each Connect to QuickBooks (OAuth) connection made. You can read more details on that here.

Customers can stop paying for a variety of reasons including:

• Customer's payment method was declined, or just stopped paying you.
• Customer was only a trial customer and never converted to a paid customer.
• Customer legitimately cancelled their subscription to your App.

These customers have likely already successfully connected their QuickBooks data, which will result in you (the developer) being charged monthly for each of these connections. 

How can you ensure that you are only being charged for connections in which customers are paying you?

1. Make sure you utilize the Disconnect API. You should be already making this call in the disconnect link you provide in your App.
2. If you have any self-service cancel/disconnect work-flows in your app, call the above Disconnect API as part of this process.
3. On a regular interval (weekly), reconcile your paying customers against your Connections report. Then either manually disconnect each customer on the report, or create a script which  automatically batches your canceled customers, and then calls the Disconnect API to disconnect each one.

Taking the time to ensure you are following the above guidance will ensure you aren't unnecessarily utilizing services which are no longer needed.

From Intuit Anywhere to IPP QuickBooks API

We wanted to let you know in advance that over the next few weeks, references to Intuit Anywhere will be removed in phases.

Why are we doing this?

Intuit Anywhere as a label which encompasses both the IPP QuickBooks API, the Blue Dot widget and the Intuit App Center opportunity has been confusing to new developers on our platform. We've listened to the feedback and are working to simplify our content to the relevant areas developers care about. The underlying services aren't going away – we're just removing the extraneous label.

QuickBooks API which had previously been labeled IDS API under Intuit Anywhere will be the core category replacing Intuit Anywhere, with the Blue Dot Widget appropriately under this topic. Going forward we'll be separating out the information related to publishing apps to the Intuit App Center under a Marketing category.

Feedback, concerns? Please feel free to leave us a comment. We want to hear from you.

IPP Platform Status

This week we are  launching a new blog site http://ippblog.intuit.com/platformstatus/ as a way to keep IPP Developers updated about issues with the platform's status that may affect Intuit App Center and/or applications that leverage IPP's services.
 
The broad categories of services that we'll update via this blog are:

• Intuit App Center
• Intuit Data Services (specifically, QuickBooks data APIs)
• Intuit Synch Manager (this only applies to QuickBooks for Windows)
• Intuit Identity Services (OAuth, SAML)
• Other Dependent Services (this may include networking, data center, or other issues)

 
For each of these services, there are 3 states: Normal, Service Performance Degraded, Service Unavailable), and will update this blog as soon as we learn about any IPP Services issues.
 
We recommend you bookmark the blog, as well as subscribe to the RSS feed. We'll also auto-publish status updates to twitter (@IPPStatus).
 
If you feel that there are issues not reported by this blog that may be affecting your IPP app, please submit a support incident with details so we can investigate.
 
Here at IPP, we are committed to providing a world-class developer experience. We appreciate your participation, and look forward to working with you.



Intuit Partner Platform Team
 

ODE to OAuth and Rest API’s and how I love thee – NOT

We always get questions about the Rest API’s and what they return versus what is returned through the SDK requests.

Well, my goal was to find an easy way to test the API’s without much trouble. To test QuickBooks desktop this was fairly easy. Just log in to workplace or your app with the appropriate company file open and in a new browser you could send the request and get a response. You could also do this with Poster and Post the body to the requested URL and you would get an answer.

Of course QuickBooks online wasn’t going to play as nice, so I had to figure out the best way to send the request. In doing so, I came across some great websites that can help make the process go smoother and help with creating OAuth signatures.

Where to begin….   Let’s get the RESTClient installed first. This is a Firefox addon that can be found at https://addons.mozilla.org/En-us/firefox/addon/restclient/. This client works well because it has the ability to add OAuth headers as well as calculating the OAuth signature when sending the request.

Once you get the RESTClient installed and running, it should look something like this:

 

Great, so now that it is installed and working, let’s move on to configuring it. This process can be used to access both QuickBooks Online (QBO) and QuickBooks Desktop (QBD) data from IDS.

1. Login to https://workplace.intuit.com and select your Intuit Anywhere (IA) application
2. Select the Development tab and make sure you have configured the QBO and/or QBD Data Source section.
3. Scroll down to the bottom section of this page and select the “Test connect to app (OAuth)” link under the Testing Your App section.

 

4. This will bring up the Intuit Anywhere Developer Playground.  Select the Connect to QuickBooks button to go through the OAuth flow for authorizing your app to have access to the QuickBooks company data. (Your Consumer Secret key will be filled in.)



5. Select QBO or QBD depending on how you configured your App above, select company and authorize.







6. Select App Menu API test from the Post-Connection Interactions section of the screen. (Your Consumer Secret key will be filled in.)



7. Now for the best part, here are your Consumer and Access Token keys and secret keys needed for signing the OAuth connections. You can also test some of the requests from this screen, but it won’t handle all the data requests, so that is the reason I am using the RESTClient addon. (Your Consumer Secret and Access Token Secret keys will be filled in.)



8. Select the RESTClient tab from earlier or if you closed it, open a new tab and start the RESTClient.
9. Select the Headers pull down and select the Custom Header. This will open a window where you will need to add the Content-Type with application/x-www-form-urlencoded as the value.



10. Select the Authentication pull down and select OAuth. This will open the OAuth window where you will put the keys from the OAuth API Console (Step 7) so that it can automatically update the OAuth signature when you make the request. When you select Insert, it will ask you if you want to automatically create a new signature each time. You should select yes. (Make sure to copy the Consumer Secret and Access Token Secret keys.)



11. You are all done. Oh, you want to see the request work. Me too. I am going to make a call to QBO services and retrieve a customer listing for my realm. The URL is the same as what you would use from the docs.  https://[baseurl]/[realm]
    1. Go here - http://oauth.googlecode.com/svn/code/javascript/example/signature.html
    2. Enter all the information requested. Yes, a majority of the values are exactly what was used in the RESTClient above except for the timestamp and nonce.  (Screen shot below.)
    3. Press the Sign button and there you go. If you captured a request from about using something like Fiddler or Firebug, you can plug in the timestamp and nonce and you should get the exact same signature as was sent from the RESTClient.

Make sure you select Response Body in the response section to see the results.



QBO Rest API’s: https://ipp.developer.intuit.com/0010_Intuit_Partner_Platform/0050_Data_Services/0400_QuickBooks_Online

QBD Rest API’s: https://ipp.developer.intuit.com/0010_Intuit_Partner_Platform/0050_Data_Services/0500_QuickBooks_Windows

There you have it. Just make sure when are going through and authorizing the company that the URL you send in matches the company otherwise you will get an error.

Here is a way to create or verify your implementation of an OAuth signature for your request.

        



I hope this helps and enjoy.

Other consoles available, but not tested.

REST Console for Chrome: https://chrome.google.com/webstore/detail/cokgbflfommojglbmbpenpphppikmonn

– William Lorfing – IPP Developer Relations

 

Update - October 10, 2012

It looks like the rest Client is not creating the signature correctly.

Here is how I got it to work correctly:
1. Go to http://oauth.googlecode.com/svn/code/javascript/example/signature.html and enter all the information for the signature.
2. Copy the Authorization header after you have created the signature
3. Go back to the rest client and clear the headers
4. Set the Content-type to application/xml (for create, update and delete)
5. Create a new header Authorization and past the Authorization Header from the googlecode page.

Then you can send the contents to QBO.

IPP Java DevKit Logger

“I’m using the Java DevKit, and my IDS calls are failing.  How can I troubleshoot?” - we get asked this question very often and the solution is to enable logging in the DevKit!

Here is an easy-to-follow, step by step guide to enable logging of the request and response XML in the Java DevKit. 

The IPP Java DevKit 2.0.7 uses SLF4j as the logging mechanism. SLF4j (Simple Logging Façade for Java) serves as an abstraction layer for the various Java logging frameworks like java.util.logging, log4j and logback. The actual framework to be used by the application can be determined at compile time by adding the static binding to the classpath.

 The DevKit implements SLF4j and includes the slf4j-api-1.6.4.jar. The logger that is implemented in the Java dev kit is “com.intuit.platform” . The acceptable logging levels depend on the logging framework configured in the application’s config file.

 

Why we use SLF4j

• Developer is not bound to use the same logging framework as the underlying library, so it gives the developer the flexibility to configure the logging framework at deployment time. Applications that rely on the Java DevKit can now use any logging mechanism – JUL, Log4j or Logback.
• Slf4j uses parameterized logging messages for improved performance.

Here’s an example that shows how to enable log4j logging for an app using the Java DevKit - HelloWorldIA is an existing Java application that integrates with the IPP Java DevKit.

1.  Bind the Logging framework - Download and reference the log4j.jar and SLF4j binding jar slf4j-log4j12-1.6.4.jar to the application POM.xml.  The jars for SLF4J binding can be downloaded from here.

Note: If no binding file is found on the classpath, it will default to a no-operation implementation. You will see the following warning message in the console log:

SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".

SLF4J: Defaulting to no-operation (NOP) logger implementation

SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details

 

2.  Configure the logging framework - Include the log4j.properties in the src folder and set the DevKit logging level as com.intuit.platform.level=DEBUG

Setting the level to debug will write the request and response XMLs to the log file. The other log level that is currently implemented in the DevKit is WARN that writes the warning messages to the logs. 

 

3.  Build & Launch - Build the app and deploy to the server. Launch the app.

 

4. Access the DevKit  - Invoke the Java DevKit by clicking on “Find All QuickBooks Customers”

 For more details on the configuration for other logging frameworks, please refer to the documentation here.

- Priyadarshini Vijayakumar - IPP Developer Relations

 

 

Announcing IPP 3.6 Release

IPP v3.6 is now live and available for IPP partners.

IPP v3.6 CONTENTS

NEW Intuit Anywhere Policies and Guidelines 

• As part of the 3.6 release, there are new Intuit Anywhere Policies and Guidelines that all Intuit Anywhere applications will need to conform to prior to publishing to customers (regardless if the app will be listed on App Center). These policies and guidelines were based on usability studies and Intuit best practices.  Please be sure to review and implement the new Intuit Anywhere Policies and Guidelines prior to publishing your Intuit Anywhere application and submitting for the security review.  If you have questions, please contact IPP Support.

There are also some additional improvements to the Platform. 

Platform Enhancements

• Application Sign-out from 3^rd party app has a new function and flow. When your users sign out of your app, you can now also sign them out of Intuit App Center. This only applies to users who sign into your app using their Intuit credentials via OpenID.
• Updated Authorization page UI – We modified the app authorization page to incorporate feedback based on usability studies.  This modified page makes it more obvious to users that they are connecting their QuickBooks company with a 3^rd party app during the subscribe and “Connect to QuickBooks” flow.
• New First-Run use gleam – A friendly note that fires only once upon completing first time sign-up or connection to a 3rd party app. The goal of the gleam is to introduce the user to the blue-dot benefits.

                    

Software Updates/Fixes

The following updates have been made as part of the 3.6 release:

• Blue Dot now displays 'Reconnect to QuickBooks' after when oAuth token is invalid
• First & Last name for QBO users will now be pass from App Center as part of OpenID
• Publish type of IA apps can be changed, “Listed on App Center” to “Create Intuit Connection” 

Please review the release notes for more information on our IPP v3.6 enhancements.

Focusing on the Future with Intuit Anywhere

Developers: you’ve talked and we’ve listened. We know there are two key things you want from the Intuit Partner Platform (IPP): access to QuickBooks data and access to QuickBooks customers and we want to make that as easy as possible. Here’s what we’ve heard from you that is not an ideal experience as a Federated app today:

• You wanted to allow customers to access your app anywhere, including via the Intuit App Center AND your own website.
• You didn’t want to have to use our billing system or user management.
• You didn’t want create a new version of your application just for our channel and therefore support two versions of your applications.
• You want us to use industry standards for authorization and Single Sign-On (SSO).

Based on all this feedback (and more!) we introduced Intuit Anywhere in August 2011. Now we’re pleased to announce, also based on developer feedback, that we’ve made the decision to decommission Federated applications and continue to invest and focus on Intuit Anywhere.

What does that mean for you?

• New Apps – All new apps need to be built using the Intuit Anywhere components. Be sure to check out the Requirements Checklist so you know exactly what is required as part of your app’s integration.
• Apps in Progress – If the security review for your Federated app has already been started, you may continue with Federated.  If your app has not been scheduled for a security review, please transition to Intuit Anywhere.  
• Existing Apps – Existing Federated apps will have plenty of time to migrate to Intuit Anywhere. By July 1, 2013, you need to make sure your Federated app has been decommissioned and all of your customers have been migrated to your integration using Intuit Anywhere

While this will require changes on your part, it’s important to note that the bulk of the work (integrating with QuickBooks via Intuit Data Services) does not require additional changes. Here is a quick look at the biggest differences:

• You will need to implement OAuth and OpenID. 
• You may need to establish your own billing system and user management (if you don’t already have that for your non-federated SaaS app). The best part of this is that you will no longer need to support two version of your application.
• You will need to adopt our updated revenue model. Rather than Intuit retaining 20% of your revenue every month, you’ll only pay Intuit $5 a month per company-connected, regardless of users. More information on the Intuit Anywhere billing details are here.

We’ll be hosting a webinar to answer all of your questions on Thursday, June 14, 2012 from 12pm-1pm PT. Please sign up to attend our webinar to if you have any questions about migrating to Intuit Anywhere.

We’re very excited to announce this decision allowing us invest and focus on exactly what you want! Thank you for continuing on this exciting journey with the Intuit Partner Platform.

Thanks,
The IPP Team

ProOnGo: Ushering in the Era of QuickBooks-Compatible Mobile Apps

The following is a "guest" blog post, by Phillip Leslie is Founder & CEO of ProOnGo LLC, maker of ProOnGo Expense and numerous other QuickBooks-compatible mobile apps. He can be reached at phillip at proongo.com

----

Thinking about building a mobile app that connects to QuickBooks? Welcome. There has never been a better time to do so!

Lets review. Just five years ago, of about 219M mobile subscribers in the U.S., just 9.1M of them hadever used a “downloaded application”. Today, there are far more than 9.1M new smartphones being sold-through to consumers every week, and mobile apps go hand-in-hand with unwrapping a new smartphone.  Combine that with the fact that there are 4.5M companies running QuickBooks, and you’ve got all of the ingredients for putting the power of QuickBooks into the hands of on-the-go businesspeople everywhere.  Want to be sure that the folks carrying smartphones are the same folks that want to get to QuickBooks data on-the-go?  Try looking at time-series relative search volume for the terms “QuickBooks Mobile” or “Intuit App”, and you might find yourself running, not walking, to your mobile app engineers.

Before You Do File→New Project

Before you crank out the first line of code, you might put some thought into your revenue model, because it may impact your architecture.  For this post, I’m going to assume that you have a SaaS revenue model, because that’s the clear trend amongst Intuit App Center apps in general.  At issue is the question of whether you should plan on building a mobile app that connects directly to Intuit Data Services, or whether you should build a mobile app that connects to your own web server that enables or supports the data flowing to and from Intuit Data Services.

If you decide on a SaaS revenue model, you’ll probably want the primary flow of data to pass through your own web server, rather than directly from the mobile app to Intuit Data Services.  That way it’ll be a lot easier for you to manage access rights based on business rules around your subscription packages.  I’m not saying this is the only way to architect a SaaS app, but it does seem to be the most mainstream approach.  For the purposes of this blog post, I’ll assume that you are building a mobile app that has a SaaS revenue model, and that you’ll use a custom server-side in part as a passthrough for inbound and outbound data being exchanged with Intuit Data Services.

First Things First

You are going to need some way for users to sign in.  You could homebrew your own account creation, sign in, and authentication code.  Whatever the reason, that seems to be a popular choice.  However, I’ll bet that you don’t consider your sign-in process to be the core of your differentiation, and if that’s the case I’d suggest letting someone else bear that burden.  Specifically, by relying on an Intuit Account sign-in with OpenId integration, you can rid yourself of the responsibility of building a sign-in and authentication system from scratch.

Want to know which sign-in pages Intuit has optimized for viewing on a mobile device?  Try launching your web browser with a User-Agent that urges Intuit’s web server to send you a mobile-formatted version of the page. For example, on a Mac with Google Chrome, you could open your browser window via a shortcut like:

open /Applications/Google\ Chrome.app --args -user-agent="Mozilla/5.0 (iPhone; U; CPU like Mac OS X; en) AppleWebKit/420+ (KHTML, like Gecko) Version/3.0 Mobile/1A543a Safari/419.3"


Launching your browser with that type of User-Agent, for example, causes the App Center sign-in page to show you it’s mobile version:

 

 

 

If you’ve built any mobile apps in the past, you probably already know how to get an embedded web browser into your app (Android: WebView; BlackBerry: BrowserContent; iOS: UIWebView). You can easily point an embedded web control to Intuit’s URL, to let the mobile device’s native browser handle the rendering and user interaction of Intuit’s mobile-formatted sign-in page.

Once you’ve got a skeleton app that presents this mobile sign in page in a probably full-screen web control, you’ll need to put some thought into a strategy for doing an OpenId assertion driven by your custom web-side code, to complete the cycle of establishing a session between your mobile device and your custom server. And, you won’t have to write a lick of password storage or retrieval code. Thanks, OpenId!

Tackling the Try-Buy flow from a mobile device is an advanced topic for another time — but the above should get you going if you’ve already got a desktop-side Try-Buy flow that is the primary starting point for first-time users.

Hybrid App Basics

I’ve already urged you to hand Intuit the responsibility for maintaining the sign-in UI, and to use OpenId to cause your device<=>server session to be authenticated by Intuit. If you do all of that, then you are probably at a point where you are thinking about hiding the embedded web control upon successful sign-in, and thinking about how to transition to your native UI that exposes the main functionality of the app.

You’ve heard that hybrid apps are all the rage, and that HTML5 is making hybrid apps even more attractive, and anytime you find yourself mixing embedded web controls with native UI you are essentially building a hybrid app. So, how does a hybrid app maintain the continuity of device<=>server session when it’s initiated via an embedded web control, but later used by your app’s network connection code (like Android: HttpURLConnection; BlackBerry: HttpURLConnection; iOS: NSURLConnection)? Although there may be some oddball exceptions, the vast majority of device<=>server session management for embedded web browsers is handled via session cookies. The rules by which the session cookies are issued and invalidated end up being specific to web server, configuration, and server-side code base, but a search for the following terms will lead you to abundant information about the most popular session handling semantics: JSESSIONID, PHPSESSID, ASP.NET_SessionId, sid.

Once you nail down the nature of your web server’s Set-Cookie headers (try Firebug or Chrome Developer Tools to verify your understanding), you are well on your way to writing mobile app code to manage the hand-off of the relavent session cookies from your embedded web browser to your customized device-side network connection code.

Consuming and Sending Data

At this point, you have a user that is authenticated by Intuit, with a session established between the mobile device and your server, and we’ve made the assumption that the Try-Buy flow was handled via a desktop-side first-use experience. If you’ve made it this far, you are in a position to begin exchanging data with IDS via your server, with the sends/receives either happening synchronously when your mobile app requests it, or asynchronously to do some predictive caching of resources that you anticipate your mobile app will need frequently. If you’ve written much web service code for use from mobile devices, you’ve probably settled on a RESTful design, and my suggestion would be that the mobile<=>server interactions should pass XML bodies that conform to the IDS data models. After all, if the destination or source of the data is IDS, and if you are aiming for a seamless integration with QuickBooks, it seems undesirable to invent an intermediate XML schema for mobile<=>server interactions. If you are worried about the “heaviness” of some of the IDS-returned XML bodies, you could certainly cull the nodes that you know your mobile app won’t consume.

I’d recommend having class definitions, parsers, and serializers for the IDS objects that you rely on most heavily. Without getting into the always-heated debate of what design pattern is most appropriate, let me suggest that in basic terms you’ll want to be able to pass around IDS objects in an object type that makes sense on your mobile device.

For example, on iOS, having objects that conform to NSObject puts you within striking distance of being able to conform to additional protocols (like NSCoding) that will take some of the load off your developers when they get around to implementing local caching of IDS objects.

We’re Out of Time, But…

There is so much more to say, for example, about:

• Managing asynchronous connections to make the QuickBooks data-driven scenarios “feel” just as snappy as if they were local to the device
• Developing a caching strategy, and a method of keeping track of dirtied objects and resolving conflicts
• Using the server-side to shield your mobile device code from having to know whether the data source is QBO or QBD

…however, these and other topics will have to wait for a future post.

Phillip Leslie is Founder & CEO of ProOnGo LLC, maker of ProOnGo Expense and numerous other QuickBooks-compatible mobile apps. He can be reached at phillip at proongo.com

 

Announcing IPP 3.5 Release

IPP v3.5 is now live and available for IPP partners.

IPP v3.5 CONTENTS

1. Platform Enhancements

NEW BLUE DOT

As some of you know, IPP recently conducted usability studies on IPP applications and the Intuit Anywhere experience. One of the findings of the usability studies was that the existing Intuit Blue Dot menu icon does not prompt user action; users did not understand that it is a clickable widget to navigate between applications and try/buy new applications. In some cases, people simply thought it was an Intuit banner. As you know, the blue-dot is an integral component of the IPP ecosystem and a important navigational element to users.

To address this issue, we tested several versions of the blue dot during usability and have decided to change the Intuit Blue Dot menu on Federated, Native and Intuit Anywhere applications to the one that tested best.

Here it is:

The image update will require no code change on your side. Also, the dimensions and method of delivery of the blue dot will remain the same so there should be no impact to the layout or rendering of your pages.

UPDATED DISCONNECT FLOW

Disconnect from “My Apps” is changing in our upcoming 3.5 release for IA applications that are listed in the App Center.  If your IA application is IA and listed on the App Center (or plans to be listed on the App Center), it will require action on your part.

What’s Happening? 

• When a customer clicks disconnect on their IA application from “My Apps”, IPP will invalidate the oAuth token and redirect the user to the page you have entered in the Disconnect URL field. Note: IPP will continue to send an email to the app developer on file, as is currently the process. 

What do you need to do?

• Log into the Dev Center (Manage App page) and verify the Disconnect URL you have entered for your app. This URL will be where the user is taken upon clicking “disconnect” from the Intuit App Center. This should be a link that takes the user to a page to reconnect via the “Connect to QuickBooks” button.
• In order to identify the user on the landing page and perform the necessary clean-up on your side, you should make an OpenID assertion from the Disconnect landing page.
  Note: This is similar to the OpenID interaction between IPP and your app during the subscribe flow from Intuit App Center.

A few notes about the way the Disconnect URL:

1. It’s a required field.
2. You have the option to make an OpenID assertion. If you do not, then the user will arrive at your page unauthenticated.
3. You will continue to receive an email when the user has disconnected the app
4. IPP Dev Relations will review your disconnect URL
5. We will be revising the Intuit Anywhere app policies (which include the disconnect user flow) and will continue to communicate to you

2. Software Updates/Fixes

The following updates have been made as part of the 3.5 release:

• Passing RealmID on app launch – Apps that allow connection to multiple companies will know which profile to load when the user clicks on their app from Intuit Blue-dot
• Reduced latency on Blue-dot menu load: We’ve made some performance enhancements on our end to help reduce the time it takes the Blue-dot menu to load
• “Enter Data directly” disabled when unchecked by developer:  Unchecking “Enter data directly” in app set-up will suppress a customer’s ability to “Try with QuickBooks Desktop sample data”  option during federated and native app signup

Please review the release notes for more information on our IPP v3.5 enhancements.

Released: Windows Azure SDK 2.0 for Intuit Anywhere

Released: Windows Azure SDK 2.0 for Intuit Anywhere

The Windows Azure SDK 2.0 for Intuit Anywhere is a set of development tools that enable developers of SaaS apps developed on Windows Azure to publish those apps on Intuit App Center, where they are available to millions of Intuit customers. 

Developers who are not on the Azure platform will still benefit from the Intuit Partner Platform .Net DevKit 2.0 and Visual Studio add-in for Visual Studio 2010 as they integrate their applications to QuickBooks data via Intuit Anywhere and .Net. 

The SDK contains the following components:

Developer Tools

• Intuit Partner Platform .Net DevKit v2.0
• Intuit Anywhere Add-in for Visual Studio 2010
• Windows Azure Templates for Intuit Anywhere

Marketing Benefits

• The Windows Azure SDK Program for Intuit Anywhere includes great marketing benefits for your SaaS app, including:

Microsoft Front Runner Program for the Intuit Partner Platform - A collaborative effort between Microsoft and Intuit

Intuit Partner Platform .Net DevKit v2.0 [Link] 

The IPP .NET DevKit has set of .NET classes that make it easier to call Intuit Data Services QuickBooks for Windows and Online. This release has full support for Intuit Anywhere. Some of the features included in this DevKit are as follows:

• Methods to call Data Services APIs synchronously or asynchronously, enabling your apps to access QuickBooks entities such as accounts, customers, invoices, and so forth.
• Ability to perform single and batch processing of CRUD operations on all QuickBooks Desktop (Windows) and QuickBooks Online entities, both synchronously and asynchronously.
• OAuth and SAML support for Federated apps.
• Reporting Service APIs for accessing QuickBooks Desktop (Windows) reports.
• Retry policy constructors to help apps handle transient errors.
• Logging mechanisms for trace, request/response, and Azure logging.
• Sync APIs that assist with data synchronization between QuickBooks Desktop (Windows) and Intuit’s cloud.
• Query filters that enable your app to retrieve QuickBooks entities whose properties meet specified criteria.
• The IPP .NET DevKit provides three different ways to log messages:
  • Trace Log
  • Request and Response Log
  • Azure Log Interface

 Intuit Anywhere Add-in for Visual Studio 2010 [Link]

• Intuit Anywhere Azure ASP.NET Template extension  
• Intuit Anywhere Azure MVC 3 Template extension  
• Drag and Drop code snippets for Intuit Anywhere Oauth, OpenId and Blue Dot components. No coding, just provide your apptoken, consumer key and secret in the config file!!

Windows Azure Templates for Intuit Anywhere [Link]

• MVC 3 Template
• .Net ASP Template

DevKit Documentation [Link]

 

 Happy Coding.

-Jarred Keneally