 Hi, I'm Rohit Nagarmal and I'm a Program Manager on the Outlook ecosystem team. Today, I'm very excited to introduce the new features that are coming to the Outlook REST APIs in Preview. Our Preview endpoint is always getting updated with new changes and this video will focus on some of those additions. To set some context, we made the version 1.0 for the API available last year and we are also launching the 2.0 endpoint now. Please look up the video from my colleague Shri Devi on what's new in 2.0 and follow dev.outlook.com to learn everything about our APIs. Note that this API is worked with both the Enterprise Office 365 and Migrated Consumer Outlook.com accounts. So what are some of the new additions? First, we will learn about how your apps can add custom data to the existing entities like messages, events, using the simple to use Office 365 data extensions. Now in spring, we had introduced sync for calendar events. Now we are adding sync support for messages and mail folders. We are also previewing support for batching requests. As this is the preview endpoint, we are constantly iterating and improving the APIs based on usage and your feedback. So there are a few key changes that I will highlight. Finally, we are also adding a brand new people API which deserves its own video, so please look up my colleague Mariana Steps video on this topic. So we have heard from many of you that you want to store custom data to entities like messages. This allows apps to both reduce the need to have local storage and provides a way to tie app data to Office 365 entities. Using the extensions API, you will be able to store structured data in JSON, right inside the entities like any other property. We will have full cut support so you can add new extension properties, read, update and delete them. They already work on the most important types like message, events, etc., and we will continue to grow this list even further. Now let's take a look at the demo. In this demo, we will create a new extension on a message and then retrieve it. Imagine if I was building a sales management app and wanted to annotate an email message with some sales referral information that men app can use. Now here is a message that I want to create my extension on. So as you can see, I'm trying to navigate to my inbox messages and I have a specific message that I want to add this to. So I do a send, you will notice that I get my response and this is just like any other regular message. Now I want to add an extension to this message. So I go to the extensions end point of this message. And in my body, I put a simple JSON structure with flat properties like company name, deal value and expiration date. I also give a friendly name to my extension com.contoso.referral. It's a good idea to use reverse DNS naming to give names to your extensions because these extension names are public and anybody could use it. So this way you might be able to get some unique value for your extension. So let's go ahead and send and you will notice that I get a creative response with the extension on the message. So it has the ID extension name, company, deal value and expiration date. Now how do I retrieve the extension? It's pretty simple. Just go to the same extensions at point that we use to create the extension and give your friendly name for the extension that you gave. So in my case it was com.contoso.referral. And when you do a send, you'll notice that I get a 200, okay. And here is my extension that we just created. So hopefully that was easy to see how we can use extensions to easily create and retrieve extensions. Followers of the Outlook REST API will know that we had introduced calendar sync in the spring. I'm happy to announce that we are introducing sync to messages and mail folders. Synchronization supports both full synchronization where you retrieve all the messages in a folder and incremental sync that retrieves all the messages that have changed since the last full sync. In addition, you can also specify a time slot in the request to do a rolling window sync. By default, the response includes all properties of a message, but you can use select to get only the properties that you are interested in for best performance. We also support other query expressions like top, order by, expand and filter. Note that attachments or messages will not be returned and your app will have to retrieve them. If the has attachments property on the message is true. Now let's take a look at demo two. Let's try and issue our first initial sync request. You navigate to the messages in the folder that you want to sync. In this case, we will sync the inbox. Now just add the preferred OData track changes headed to the request. There's also an optional parameter called OData max page size. This just defines how many items you get back in your request. So once I send the request, you will notice that I got a 200. I have my five messages, and in the end, you will notice there is a delta link. This is the URL that you make for your subsequent sync request. So you copy and I paste it there and do a send. And I get my next set of messages, five messages, with a next link this time. From now on, you just continue calling the next link URL until you do not see any more next links. When you see the last delta link again in your response, it means that you have reached the end of your initial sync. You can now decide to store this delta link URL and use it to do incremental syncs later. Hopefully this was simple. A rest request requires an HTTP connection between the client and server, which incurs a certain amount of overhead. Patching enables you to reduce connection overhead by combining multiple rest API calls into a single HTTP post request. A batch request can include up to 20 individual calls, which can be a mixture of data queries like get or change queries like post or patch. You can even specify a preferred header with value odata.continue on error to have the batch continue, even when one of the requests in a batch have failed. Patching is especially useful in synchronizing large amounts of data. API calls in the same batch can access different resources such as messages and events that belong to the same mailbox of the sign-in user. Now if you need to make more than 20 calls or if the order of completing calls matters, use multiple batch requests. Now let's take a look at the last demo. Let's use an example to illustrate batching. All batch requests have to be made to the API beta dollar batch endpoint. Notice that the request has a header content type with value multipart and a boundary parameter with a batch ID. The batch ID identifies a batch and is used to delimit requests within the batch. It can be any distinguishing string. In the body, we have the request that we want to include in the batch. I have two requests. The first one is to send a mail and the second one is a get request to get the events of this particular user. They are delimited by the batch ID and end with the batch batch ID value. Now let's send the request and you'll notice that I got a 200 response for my overall batch and within that for the first one, I have a 202 accepted which is for the send mail which means that was successful and for the second one, I got a 200 response which means I got all the events. So hopefully that illustrated how simple batching was to use. The beta or preview endpoint is where we push our new features and changes first. This allows us to get your feedback and vet the APIs before we decide to move it to a version endpoint. We encourage users to not point their production apps to the beta endpoint because we occasionally make breaking changes to the APIs. Here are a few notable changes. Within name change, as you can see that a bunch of property and entity names have been changed. For example, folder entity has been renamed to mail folder and all datetime property names have been updated to have datetime show up in the end of the name. For example, datetime send has been renamed to send datetime. User photo, group photo, contact photo has been updated to just photo. East contact photo has been removed from file attachment. Now there are also a few other changes to time zone, reminder and notification features. For the details, I would ask you to look at the dev.outlook.com site. Another useful tip is that we use the exchange dev blog at blocks.msdn.com slash exchange dev to announce these changes before they are rolled out. Finally, these are some of the resources that you can use to learn more and give us feedback. Thank you.