 Hello and welcome to my lightning talk about using OpenAPI for automated API documentation at next slot. So you might have heard about this already in the res presentation, but I will go into more technical details on how this works. So you might not even know what OpenAPI is. So the OpenAPI website says the OpenAPI specification is a specification language for HTTP APIs that provides a standardized means to define your API to others. So, well, what does this quote even mean? Well, it means you can document your API in a way that is decoupled from any programming language. You don't need to read and understand the implementation of the API. It includes common concepts and patterns that are used in HTTP APIs and it also makes it possible to transfer the knowledge about your API. So how do we get an OpenAPI specification in the context of next slot? We built a tool called the OpenAPI extractor that generates the specification. It helps you change the make the necessary code changes in your app that are required to support OpenAPI. It shows you errors and warnings about stuff that might be wrong. In most cases, it is wrong, actually. And in the end, you get a full specification that works. The analysis of the code is based on type annotations that you add in the code. So it doesn't actually affect the code itself, but rather the code comments. Those annotations are then validated by a static analysis. We use plan for that. And that makes it possible to always validate that the documentation comments and the code itself are in sync and you never have broken documentation. We also have a tutorial available for developers to adapt their apps so that they can leverage OpenAPI as well. So what does it mean for next slot? Well, we have all the server apps available. So they have been documented. We also work on more apps that are not part of the server itself. For example, talk is basically done just some minor bug fixes required. The documentation itself is scalable and you can make sure that it's always up to date by using CI. This allows you to also find mistakes in the API while I was documenting all the server apps. I found multiple bugs in the implementations for some corner cases that probably never occurred yet, but still there were bugs. And using other tools, it's now possible to make sure that you don't introduce breaking changes in the API. So that can also be part of your CI pipeline. So what does it mean for you? We have multiple ways to interact with the documentation now on docs.next.com. You can find all the documentation itself, but it's not really interactive yet. But we also have a new app called the OCS API Viewer, which also was mentioned in the release presentation. It allows you to explore the APIs that are available on your server. So you can actually try out the endpoints, send a request, get the response, see it all happen on your server. And this app is also installed on the conference instance. So you can already try it out there without having to install anything. And lastly, you can use an open API generator to generate client code for the open API specifications. But we also have that available for some languages, for example, Python and Rust. What's next? So we will work on supporting more apps in the future. Of course, it would be nice if everyone appreciates this and also starts adapting their app to support open APIs so we can have even more documentation that's automated. Later today, there will be a workshop as well, where we can discuss and if you are interested in this, also either work with the generating client code or adapting your app if you're interested in that. And later on, there will be in a few minutes, there will be another lightning talk about the Neon framework, which utilizes those open API specifications on a great scale. So if you're interested in that, you can also listen to that. Thank you.