One Year of OneNote API, One Updated Roadmap


Technorati Tags: ,

Hello fellow OneNote API travelers. Gareth here, wearing a paper hat and eating a slice of birthday cake. I can’t quite believe it’s been a whole year since my colleague Steven posted our first entry on this blog for the OneNote API launch.

What a year it’s been – we added an amazing set of partners, a host of updated features, samples, and integrations. A whole bunch of conferences where it’s been our privilege to meet many, many customers and get great feedback and ideas. A vibrant UserVoice community is visibly driving our backlog with 22 completed user requests.

We have videos to get you started across all platforms and API documentation with integrated ‘try before you buy’ web consoles so you can kick the tires on our APIs without writing a single line of code.

Phew! But, I hear you ask, what is coming next? We’ve always been pretty open with what we’re working on by updating our uservoice requests, but we haven’t updated our consolidated roadmap for a while. Let me fix that now. The list below is what we are currently working on and planning to work on next. Don’t worry too much about the specific order. We are actively working on the first three at present, and all are pretty large projects. After that, the order is more speculative and of course our priorities will likely adjust as we go along based on what we hear from customers.

  1. Office 365 version of our REST APIs, supporting both OneDrive for Business and SharePoint-site hosted OneNote notebooks. Currently our API only supports Notebooks stored on our consumer OneDrive service. We are expanding that to support all notebooks stored in the Microsoft cloud.
  2. WebHooks for OneDrive-hosted notebooks. Lots of applications need to react when a user makes an edit to their notebook and the industry-standard way to support this is via webhooks. We’ll start by bringing these to our OneDrive-hosted notebooks.
  3. Client SDKs for our REST API. Some developers really want client SDKs for their platform of choice. We’ll start with iOS, Android and .Net.
  • Updated samples. We have great samples. Across a lot of platforms. But we’ll hold up our hands. We haven’t been as great as we’d like at keeping them up-to-date with all of our new features. We’ll give these the renewed focus they deserve.
  • Ink support in the REST API. Digital Ink in OneNote is amazingly productive. When you see how naturally kids in schools use ink with OneNote on a Surface Pro 3, it makes you want to see apps tightly integrated into this ecosystem.
  • Copy a shared notebook to ‘make it mine’. Publishing broadly available content with OneNote is really simple using anonymous sharing on OneDrive. But today it’s not simple to create an experience for your users to take a copy of that content into their own notebooks, personalize it and start adding their own value. We’ll provide APIs to make this very easy.
  • Better tools to help users find OneNote integrations. We love our app gallery, but we can do more to help showcase all the great work you, our partners, do with the OneNote API to the broader OneNote user community.
  • Allow live OneNote pages to be embedded on a website. This is riding high on uservoice. We know you’d love to integrate OneNote’s great functionality directly into the UI of your app. We’d love you to be able to do that too.

Let us know via uservoice whether we’ve got this right and help us prioritize the list.

On behalf of the whole OneNote API team, we can’t wait to see what you do with your apps and OneNote in the next year!

Comments (2)

  1. Gareth Jones says:

    Interesting suggestion Brandon.

    Please can you log this in the developer section at onenote.uservoice.com and see if others want the same thing?

  2. Brandon Paddock says:

    Really great to hear that WebHooks are coming. I'm hoping these will enable easy integration with Slack (which will work better than the hacky polling solution I have to use now, which encounters lots of OneNote API bugs and limitations).

    However, one question that comes to mind when reading this… Why would you make a .NET client SDK and not a Windows Runtime one? I get that a .NET SDK would be useful for servers, but for Windows and WinPhone app developers, you really need to write a native WinRT component (using C++ or C++/CX) so that those of us who don't use .NET in any of our apps can actually use it. You write one WinRT component and it'll work for C++, C#/.NET, and JS apps (which is the only way this will be useful to top apps like Tweetium!).

Skip to main content