Oktane18: Okta API Products Roadmap -- Going Beyond Today's Customer Identity Needs

Speaker 1: Okay everybody, thanks so much for joining us in this session today. How did everyone like this morning's general session? Was it awesome?  Yeah, just the beginning right? So welcome to Okta API Products Roadmap: Going beyond today's customer identity needs. Have a little bit of housekeeping to share with you. So, if you'll look in the seat you sat in, you should see a little postcard. If you're way in the back and you don't see a postcard, that means you should scoot forward a bit and fill in some of these front seats. These are what you'll see in each session today. They are a survey so you can let us know how we're doing, what you enjoyed about the sessions and what you hope we might add to or change next year. So please take a second to fill that out at the end of the session and pass it off as you leave today. A few things for you to know, this presentation may contain some forward looking statements, you'll want to refer to the details about that in the accompanying slides for each session. This session is being recorded. So if you would take a second right now, silence your phones, we want to be sure we don't capture anybody's cool ring tone in the middle of the demo, just shut those down if you would. If you'd stay in your seats once the presentation has begun we don't want to capture everyone up and down the aisles as well. So, that would be great. With that I want to take a moment to introduce our speakers today. With us we have George Kwan, he's the Director of Product Management at Okta. As well as Tom Abbott who's the Director of our Developer Platform Product Management at Okta. So let's give them a warm welcome and I will hand the stage over.

George Kwan: Hi everyone. Good morning, can you hear me okay? We're really excited to be one of the first sessions of Oktane18. We had a great morning session, we have some really good content today. I'm George Kwan.

Tom Abbot: Tom Abbott.

George Kwan: We're going to talk a little bit today about how Okta API products can power identity for any application. We'll talk about what's new, what's coming, we've got a demo planned. So, if you're in the back, definitely move forward so you can see the screen and all the fine details. Pick up your stuff, make your way forward. Before we get started, we're going to try to get to know you guys a little bit. So a couple quick questions, we'll poll the audience. How many folks here have a customer identity or external identity project underway right now, or planned? Raise your hand. Pretty much everybody, right? Yeah, so we're going to have some great content for you today.

Tom Abbot: And how many people are developers or engineers? Oh wow.

George Kwan: Wow.

Tom Abbot: Good crowd.

George Kwan: That's awesome. Then last question, we got to gauge the energy in the room here. Who had breakfast this morning? Oh pretty good. I was going to say it's the most important meal of the day, you can't miss it. So those that didn't have breakfast, this session is going to be so enthralling that despite your lack of energy, you're going to be on the edge of your seat. With that, let's begin. Clicker, there we go. Battery is low. I think the clicker didn't have breakfast this morning. Okta has learned a lot in building this application. So many of you may be familiar with this. This is our employee SSO dashboard. We've learned about how to manage complex security requirements for accessing an application like this. We've learned a lot about user experience. Believe us, when our customers and their end users experience friction in logging into this product, we hear about it. It spoils their day. We learned a lot about security, about end user experiences and we're taking those learnings and putting them into our API products for you to use to serve as the identity layer for your application. Okta can power identity for any application, whether that's a customer facing application, a partner facing application, and regardless of the size of your project. We have customers who are just looking to add some additional security to an existing application. We have folks building new applications for their end users, whether they're customers or partners. We have enterprises who are looking for an identity platform to power identity across all the applications that are being deployed enterprise wide with a single branded experience for their end users.

We have our customers using API products in really interesting ways. When I talk about identity and the identity layer, power identity in your application, what do I mean? I mean these core identity experiences. Registration, logging in your users, managing a recovery flow, MFA. At first glance these experiences look pretty simple. User name and password field, right? But as you all know, getting identity right is complex. It's all of these edge cases, all of these details. How do you reset a password? How do you enroll MFA? How do you verify an email address during registration? All of these details are difficult to get right from a security perspective, from an end user experience perspective. It slows down your projects. It adds time. It requires more engineers. You don't want to have to worry about any of this stuff, you want to focus on building your application and that's exactly why we built API products.

Tom Abbot: The base of API products comes down to the policy engine Todd was talking about earlier. In that if you guys have used Okta before you probably are very aware of all the policies that we have in the product. So this includes registration policies, MFA policies, how the user can unlock their account. These are really the base of the product. What we've done is on top of it we've built an authentication API. How customers use it today is they either do one of two things. They either decide to build their own UI on top of the authentication API, to bubble up this functionality to their end users. Or they decide to use our widget, click, and they use the widget. The widget is primarily just a consumer of the authentication API underneath the hood. What we've announced recently with a lot of features that we've currently made available as early access, is the ability to host this in a fully customized fashion including the login URL, the HTML on the page, to really create a log in experience or a log in portal that you can use for any application. So if you want to take the URL and make it instead of yourapp.okta.com and make it login.yourapp.com, or even build out something that looks very close to the accounts.google.com scenario, this is exactly what you can do with Okta today.

The other nice thing about Okta is when you use API products, you actually get all of the rest of the functionality that Okta is known for underneath the hood. So, if you have any sort of advanced life cycle management types of scenarios, or scenarios where you need to use an AD agent to pull in users and get them available for your applications, these are all readily available as part of the API products as well. I think one of the more interesting areas of API products is, you know we could build APIs for days, but it's not going to really do anything when it comes to making your developers successful in your org. For the developers to be successful, we've actually had to take an approach which is to give them a brand new developer console which bubbles up to the functionality that they need to be successful to primarily create an application, then get them coding as quickly as possible. We try to do this in 15 minutes or less. That's an internal goal that we have for our engineering team. On top of that, not every company develops in the same language. I think if you take a look at the stats of Okta, a lot of you guys are Java developers, although we also have .net developers. We even have companies that are Polyglot, they allow their developers to pick the tooling that they need to be successful. So the only way that Okta as an identity company do be successful here is we provide SDKs for every language under the sun.

Somebody's sneaking up behind me. If a picture's worth a thousand words, a video is worth, I don't know how much?

George Kwan: A million. Maybe a million.

Tom Abbot: Then what's a demo worth? A live demo?

George Kwan: A lot of zeros.

Tom Abbot: A lot of zeros. I could get up here and talk, but let's go ahead and try to build something. What I want to do in this demo is show you how we can take one of our default sample applications and get it wired up to that accounts.google.com, the login portal that Okta provides for your applications in about 10 minutes. To start out let's go ahead and just take a look at what we provide developers today. Who's been to developer.okta.com? Out of curiosity? Oh so a lot of you guys. Actually, I'm not even going to show you guys it. Just very quickly. This is primarily where you get all your information. We also have a lot of sample applications associated with what you're building. What I'm going to do today is I'm actually going to build something using our React sample. So our React sample, open source on Get Help, has a couple different modes of operations. You can get it to operate in Okta hosted mode. This is where we host the login page. Or we also have a sample where you have a custom log in page. This is a log in page that you host on your application server. For this, we're going to be using the Okta hosted log in page.

I actually already have it cloned, set, ready to go. It's actually deployed on local host for this demo. How many of you guys have grown a sample application before with Okta, out of curiosity? All right, not too many hands, so this is probably going to look brand new. This is just a React application that's already wired to use the Okta tooling. When I click the log in button there since I have really configured it yet, it's not really pointed anywhere worthwhile and it's just not going to work. So, the first thing that we're going to do, is we're going to go into the Okta developer console and create an application. So, very quickly, we're going to go to tomoktafreeoktapreview.com Log in and create an application. Passwords suck right? So very quickly click on application, add application. You can create any application within Okta. Primarily, I think if I took a look at the stats today, primarily people are building web applications. We do have people that are building native mobile end SPAs. I like SPA technology, I think it just makes things very simple. So since we're a React application, just click next. We can quickly get you to the quick starts if you want to take a look at the code. But I'm not going to touch any of these settings in here. Actually, I might rename this 'myawesomeoktanedemo' that will hopefully work. Click done and we're off to the races.

So, first things first. Just need to make one small configuration change within Okta, I actually changed this log in or out because I was doing something silly, but code is code. I'm also going to copy the client ID. The client ID is how primarily Okta understands what application I'm running. There's one small thing that I've also configured in my org before the demo and I just want to show you guys what that was real quick. This org is actually configured for the custom URL domain. This means that my org can actually serve underneath another domain. So, this uses just, you have to upload your certs to Okta, you have to do a little bit of DNS magic with the C-name, but this will actually be hosted on login.tomabbot.com

So, to get my application, my React application configured, up and ready to go with that client ID, and with that vanity URL, we're just going to quickly add the client ID and issuer to the space. Did you guys see this in the keynote earlier? They were just playing around with Jason. This is how all of our sample applications work. Oops, almost forgot vim for a second. And we're going to change this to login.tomabbot.com Save that, reacts going to recompile and if I go back to my application, log in should hopefully work, unless I copied something incorrectly.

George Kwan: Yay.

Tom Abbot: So, click the log in button, login.tom-abbot.com So we now have a log in page and believe it or not it will work exactly the way that you'd expect using the sign in widget, using authentication API underneath the hood, set, ready to go. So it understands who I am. This application's pretty silly. It just shows how to get logged in, how to hit an API and then also get some profile information so that your application can understand the context and who it's running for.

All right, so if we take a look at where we are right now, we have a log in page and that log in page doesn't look very good. It doesn't have sign up, it hasn't been configured for MFA. Let's go ahead and just knock all that out and try to get on with the presentation. So back into the console,

Tom Abbot: The ... console. First things first, let's configure that application for multifactor. This is going to be my magical secure B to C type of application, so as you guys probably imagine, I'm just going to go in and add a sign-on policy rule. I'm going to prompt for multifactor on every sign-on, and just click save. Uh, shame on me ... Being all cheeky. Let's see, multifactor, so let's do self-service registration. New feature in Okta- have you guys seen this thing yet? First time seeing self-service registration? Nobody was in the beta? We had sixty customers in beta, so ... Okay. Self-service registration, first time. So, self-service registration, believe it or not, by the name allows your end-users to sign up for your org. So, to enable it, all you have to do is enable it, and pick which group they're going to get assigned to. This actually controls the password policy for that particular user creation. So, if we quickly pop this open- my password settings- eight characters, not doing anything super fancy, don't really care for upper case/lower case but I just want to make sure they're not setting their username as a password.

And the other things you can do with self-service registration is you can actually set up the login form. My login form is really basic right now- just email and password, but I could force any sort of requirements around fields. And this is actually based on the Okta user schema, so as long as you have your schema set up for your required attributes, unrequired attributes, you can actually pick and choose how this is going to look in the login form. And then we also have a checkbox to figure out if Okta is going to force the user to go through email verification to actually activate their account. And click save. Didn't forget to name something, awesome. Okay. Next. Let's take a look at customizing this page. So, we saw it wasn't very pretty. My application's sort of like a darker type of application- darker theme, I guess is what I should say. So, we're going to customize the sign-in page. So, how many guys have seen this before. Alright, so we had a few people on the beta, awesome. This is how you customize the sign-in page. We give you carte blanche control of the HTML, so you get the ability to put whatever scripts you need to on the page- any styles. We've also added configuration for the widget so you can pin it to a particular widget version if necessary. We go ahead and pin to a major version, if you guys are familiar with SemVer, this will make sure we don't break backwards compatibility. And then the minor version, we have a macro to point to latest, so you can get the latest and greatest without breaking backwards compatibility. But, if you want to pin the minor version, for whatever reason, way, shape, or form, you can do it.

And we have the other settings for the login page that you can just configure just as is. So, if I wanted to do a custom sign-in text, you can do that. But, let's customize some stuff. Page title will default to your org name- that doesn't really work here, so I'm just going to call this Oktane demo. And we're going to add a ... where is it? There it is ... We're going to add a style sheet to the head, for the style. Tab that over because it's absolutely necessary, right? And then the other thing that we need to do is, we're going to enable registration for this page. Registration, right now- you need to force the widget to actually show it, so we're going to do config features registration. This is straight off of the widget README if you're curious, or this isn't like some magical code. Pretty simple, we're just adding the registration feature. We do have preview of what this will do- is this will pop it up into a brand new page, and you can see custom sign-in page which matches my application a little bit more. Also, has a sign-up link, that was added to the bottom- that was the whole config features registration- true. And we're set and ready to go. So, let me save and publish this. That looked good. Let's go back into incognito mode co-session sharing is a thing and see where we are. So, login link- click that- Pops me over to my nice pretty login page- looks nice for my application, we can actually go through and sign up a user.

So, this is the most typing I have to do in the demo. Tom Abbot Okta at outlook dot com. I'm just going to go ahead and create an account. Sent me a verification email because that setting was checked. We're going to now go into Outlook. And I have a activated account. I've already customized the HTML to make sure it looks a little bit closer to my application- spared no expense on this design. Got a new unread Skype conversation and an ad- don't know what that is. Click verify account. What happens is- I'm getting redirected back to Okta because I need to enroll into multifactor. This is a brand new account- multifactor was configured, enrollment policy was configured- so, we're going to go ahead and set up multifactor. Do you feel like SMS is going to work?

George Kwan: Yeah, why not? Feeling lucky.

Tom Abbot: Yeah, it's Vegas. Also, don't write my cell phone number down, please.

George Kwan: Tom's looking for new friends, so ...

Tom Abbot: Alright. If I typed that in correctly, I should get sent back to my application, and now you can see all the fun stuff about my accounts, who he is, what his locale is, email verified is true, so you can get these big pieces of information through OAuth 2.0 OpenID Connect. Sigh of relief.

George Kwan: You deserve a little break after that, Tom. That was very well done. So, in about ten, fifteen, minutes or so ... Tom started with sample React app from dev.okta.com, added sign-in recovery, MFA, registration, by configuring a few simple policies, by customizing the look and feel of the page, and serving that up at a vanity URL. A few new features there to go home and try- registration, yay, custom hosted pages, yay, vanity URLs, yay, custom error pages, yay. All of those features together are really what power this out of the box experience for adding identity to any application- pretty cool stuff. So, I want to switch gears now, and we're going to talk a little bit about the future. So, API products- our mission is really to build a platform that developers love and enterprises trust- that they trust for their identity layer, regardless of whether that's a single application or an enterprise-wide use case. And we're making investments here constantly to stay in the forefront, to make sure that you are able to incorporate a modern identity experience in your application. We're investing in end-user experiences, and delivering security and privacy by default, extensibility and integration in the platform- so that you can leverage the out of the box experiences, but also customize, and add your own logic and flows. And finally, as Tom mentioned, making sure that your developers are successful- that there's as little friction in the development process as possible, so they can focus on building out their application. I'm going to dig into each of these and talk about what's coming next, starting with our end-user experiences. How many of you have visited a web application, application, recently and forgotten whether you logged in with Facebook, or with a password, or even if you had an account? Happens to me all the time. Yeah, the hands started shooting up. The future to removing this friction is really identifier first. Have your users identify themselves, and then Okta- the identity layer- can walk them through the different scenarios. If they're a known user, present them a password. If they logged in with social, redirect them to Facebook, or maybe a different third party IDP, leveraging IDP discovery and whatever routing rules you've set up.

And finally, if they're an unknown user, you can present them with a create account registration experience. So, identifier first is really something we're going to be building out across all these experiences to optimize that end-user experience. And as we talked about this morning, and was demonstrated in keynote, we're moving towards a password-less world. Users hate passwords, administrators hate passwords. Being able to deliver through a set of modern factors, a push verify experience, as primary off. User doesn't have to remember multiple passwords across sites. Click a button on their phone, and access is granted. We're going to be delivering this in our API products for you to integrate that experience into your applications. And, while we support a range of the top social providers out of the box, we know that depending on your region, your part of the world- maybe you're industry or vertical- you need to be able to support a wide range of third-party IDPs. So, our federations team is working on supporting any third-party IDP that supports OpenID Connect standard. And you can integrate that into your application, route to that IDP and have the user login that way.

Shifting gears to security and privacy- again, this is a big reason why you're leveraging Okta's API products- you don't want to have to figure out how to get this right. And it all starts with a broad set of modern and secure factors, a range of different assurance levels, a range of different user experiences. We support passwords, email, SMS, Verify- as we showed- Phyto tokens, a wide range of factors for you to choose what that experience is, and what the assurance level is in your application. And none of that really works unless you have a dynamic policy that is challenging your users with the right factors at the right time. And as we discussed this morning, this is really made possible by our adaptive policies that can incorporate what application the user's accessing, their identity, their context of that session. And eventually, and coming soon, Okta thread insights, to really inform a contextual response, challenging the user with the minimum set of things they need to present for the right place and right time. And we mentioned that registration, self-service registration, is EA, this is a great experience for users going into your consumer application, but there are more secure experiences where you maybe want to gate that registration with a few additional steps. So, what are we planning next? A set of friction points in the registration experience to really gate who gets access to your application. We want to be able to offer email white listing, so it's a company that you trust, a partner that you trust, or maybe exclude personal email addresses. Approval processes, staging a user and requiring a manual workflow before that user's in your application, and extensibility- which I'll talk about a little bit later- to be able to call out during the registration flow for additional verification requirements that you may have.

And, how you handle user management is another important step to securing your application, and we're excited to be able to introduce a flexible set of automation rules that you can use for a variety of use cases in user management. If you want to suspend accounts that have been inactive, if you want to email your end-users when their passwords are about to expire, that's all possible with our new triggers and actions framework. That's going to support a wide range of triggers and actions. That includes, like I mentioned, login activity, password expiration and, on the action side, the ability to control the lifecycle of the user, or notify them. And we'll add additional scenarios over time, for example, cleaning up incomplete registrations so that that identity isn't parked, and that identity can be recycled. And finally, we've talked a lot about user accounts and identity, but what about securing and protecting your resources and API end points that are used across the applications in your enterprise? This is where our API access management product comes in. Securing those resour

George Kwan: … API access management product comes, securing those resources even powering a consent flow to allow third parties to access that data on behalf of your users and having a consent experience for your end-users all made possible by this great product, continuing to invest in API gateway integrations, in token-based reporting, additional extensions to OAuth 2.0 for Fapi Heart and adding additional security and encryption features to that offering. Okay, great. So, we've made it to extensibility and integration. This is really a key part of our product. As many of you know, Okta API products first and foremost provide a very out of the box experience like Tom showed. Policies that codify that workflow, that state machine all of the security requirements, out of the box end user experiences, but we know that as you are building more complex customize applications on top of Okta, you need the best of both worlds. You want the out of the box but you also want to be able to extend. We're doing a number of things around extensibility this year. The first is webhook support. So, Okta is generating a number of events through those registrations, sign in recovery MFA flows. We want you to be able to be notified and hook in external workflows into those events. We'll allow you to register for a subset of events that matter for your use case. We'll HTP post to your back end, your server and allow you in your code to be able to extend workflows off of Okta. This is something we're working on as we speak.

Outside of event base orchestration kind of trigger and action, we're also looking at providing more hooks into our flow. So, the authentication pipeline, the authentication flow, we want to be able for you as a developer to insert a breakpoint during authentication for example and say Okta policy deems this as a successful login, but I can insert my own policy logic, my own third-party authorization data and control and change the flow thereby extending the capabilities of Okta. We have a number of places where we're going to be inserting extensibility and this is really going to enable a lot of interesting use cases for you developers out there. Finally, the same thing for registration, user registers. Before you complete that valid registration, maybe you want to layer in some data and append that to the user's identity. We have customers who need to verify that a partner is in salesforce before you allow that registration. So, allowing a call out to verify their partner ID in a third-party database. Post registration, completing post registration workflows like creating a CRM record, progressively profiling the user with your own experience.

To recap, extensibility really important to allow you to leverage out of the box Okta plus layer on your own logic and custom workflows. We're going to be supporting webhooks on top of events and breakpoints in extensibility and the off flow and registration flow.

Tom Abbot: Awesome. Even though we've just gotten started with developer agility, we're nowhere closer to done. So, from an API standpoint we want to expose all the APIs that we're leveraging for email verification, registration and even MFA only to make sure that we have a composability story. You pick the part of Okta that you need to use for your application and we make zero opinions on how you're going to use those components. We're introducing new SDKs, the authentication API is primarily served by client-side SDKs. We want to add support for the authentication SDK server site as well for custom server-side flows as well as introduce Golang SDKs. Then last but not least, a universal directory. We have an initiative to start to unpack a lot of the assumptions that Okta has made as an IT SaaS product to make sure that they can use UD for other scenarios outside of IT. The last thing we want to talk to you about today is the new pricing and packaging. So, if you guys were listening to the keynote, we've introduced a new tier called One App which sits right in between our developer tier and our enterprise tier. This is everything that you need to get started with one application in Okta with plenty of OIDC clients so that you can support one application across different interfaces such as web and mobile and even have a couple clients left over to do like test and dev.

George Kwan: Great. That's pretty much the end of the presentation. Just recap a little bit. We talked about Okta API products and how it can serve as the identity layer for any application solving registrations, sign in, recovery, MFA, out of the box, hosted, customizable so that you don't have to. Of course, you can drop down to using our SDKs or APIs. We're investing in a number of areas across our API products making sure that we can deliver modern and user experiences with identifier first and password less flows. We're adding security features, leveraging a lot of what we talked about this morning with a wide range of factors and adaptive policies and threat insights. We're adding additional workflow on top of registration. We are continuing to innovate on API access management.

Extensibility, allowing new developers to extend Okta to customize your flows and finally never dropping the ball on developer agility, making sure that we're removing as much friction as possible to make Okta a loved developer experience. I was going to mention check out developer.okta.com because I expected a lot of people not have seen it before but it's great to see the developer community at Okta growing, the awareness of our API products this offering growing and we're excited to see what you guys build on top of Okta. Thank you. So, we'll close out the session with just a few shout outs to some upcoming sessions if you want to learn more about OAuth and Open ID Connect. We have a great session at 3:45 for you. Customization, all the things we breezed by very quickly in this presentation, [Jade 00:34:59] on the product management team will be walking you through that for how to customize the out of the box experience with Okta. The future of identity proofing or identity and identity proofing with our partner experience really hands-on talk on how to add additional flows and identity complex scenarios inside Okta. So, definitely check those out. I think we have maybe a few minutes for Q&A. We'll do three or five minutes of Q&A. So, raise your hand, stand up and I think we have a few mics out in the room. Start up front here. Yeah.

Speaker 2: Where can I find these charts of the video?

George Kwan: Do you want to speak into the mic real quick just so that …

Speaker 2: So, where can I find these charts of the video that you presented today on your website?

George Kwan: The charts? Sorry.

Speaker 2: PowerPoint slides.

George Kwan: Oh slides.

Speaker 2: Yeah, slides.

George Kwan: Yeah, actually I think we definitely record the entire session so that will be available to everyone to rewatch and sharing in organization. The slides I'm not so sure about but the video definitely will be up there. Yup?

Speaker 3: The .net SDK was rebooted after a new development team took it over and it's still rather limited. Is there any timelines available when that will be expanded further?

Tom Abbot: Yeah, we're pretty agile environment. So, for Doc. and SDK in particular we started off with doing the open ID connect side of the house. We're just currently moving back to the management side of the house. So, the management SDK, so right now I think it just supports users and groups from a management API perspective and we're planning on adding the other supports for the other top level Okta objects this year.

George Kwan: Great. Any others? One up here. Yeah? I can repeat your question.

Speaker 4: Where do you see yourself going with native app integration in Okta?

George Kwan: Tom, do you want to take that one with-

Tom Abbot: What do you mean by that? Did you guys hear the question or-

Speaker 4: So, we're developing native applications, iOS and Android. We want to use Okta as the identity provider, but we want to control the user interfaces, right? So, how do you guys see yourself extending the SDKs to a lot of our developers to build that out and do some of the device registration things you guys are currently doing in web?

Tom Abbot: That's a very good question. So, right now with iOS and Android, we've leaned towards what's called the app UX model from open ID foundation. Unfortunately what that means is like from an end-user perspective is it's a redirect flow to a web browser. There's a lot of applications that are starting to unify in that pattern. Our initial versions of the SDK hedged our bets that that that might be the way in the future, that people might develop their applications. There's obviously other scenarios for developers where they truly do have the embed scenario.

They want to own the end-user experience natively. Our approach to this is very similar to the same approach that we've taken with the Okta sign-in widget. We want to start exposing an authentication SDK and Java that's meant for Android and also Swift as well so you can start to leverage those APIs and that will be the foundation for us to start to build components that then you can leverage, customize on top of it. So, that's a higher level strategy. Unsure about the timeline associated with this. We haven’t really kicked off a lot of these things quite get but right now for native Android and iOS experiences, we are defaulting to the app UX strategy. For people, we do have a few customers that have built native experiences today. What they've had to do is drop down to the rest API and expose that via Swift or Java.

George Kwan: One last question I think.

Speaker 5: So, you mentioned regarding the self-service registration flows and the many features coming up like webhooks and all this stuff. So, I'm really interested on those webhooks features and the pre verification, post verification events. So, when do we expect that to be available?

George Kwan: Yeah, great question. It's probably one of our most requested roadmap items. So, we're actively in development of both webhooks and those breakpoints and the registration and outflow. So, we're making progress already. I think we expect to beta and able to engage with developers in the next couple quarters so definitely this year. Okay, thank you so much everyone. Enjoy the rest of Oktane and the rest of the sessions today.