 Another feature that is particularly relevant to API use and developers that are interacting with DHS2 is the introduction of personal access tokens. So personal access tokens are a new API authentication method, which is similar to and a replacement for basic auth for using the DHS2 API. Similar to using basic authentication where you pass the username and password with the request to DHS2, a personal access token is scoped to a specific user. So it's recommended if you're using personal access tokens for scripts or integration services or those types of things to create a user specifically for that integration and then create a personal access token for that user. This way you can control the rights that are granted to that user so that they can be given exactly the access that they need and nothing that they don't need, and that will help to protect the data that is accessible using that integration. This is the recommended approach for authentication when building any sort of server-side integration or script. It also supports browser-based access to DHS2, though that's not recommended in most cases if you have public DHS2 instances, unless you also implement some rate limiting and caching in front of the server to protect it from public access. Importantly a single user in DHS2 can also have multiple personal access tokens that can each be configured independently for different security rules and access controls. And then those personal access tokens can also be deleted. So if one is ever obtained by someone that shouldn't have access to it and instead of needing to delete the user or change the user's password or lock them out completely or something like that, you can remove that specific personal access token which was compromised and no longer allow anyone with that personal access token to access DHS2. It's also important that these are used for API authentication, but you can't use a personal access token to log in to the interface of DHS2, which is another level of security when using this over basic authentication because if you accidentally expose the username and password for a particular user, then someone that has access to that can do everything in DHS2. It can log in, can create new personal access tokens, can do everything else. So this is another advantage of the personal access token over basic authentication for APIs. This is a screenshot of the interface for creation of these personal access tokens. I'm actually going to go ahead and demonstrate that so that we can see how that works. So here I have a 237 version of DHS2 on the play servers. I'm going to go ahead and click settings for my particular user. And then on the left here we have a new item which says manage personal access tokens. I click on that. I have the option of generating a new one. And this is that interface that I was just showing in the screenshot. I'm going to show creation of a server or script context personal access token. I then have some options as I mentioned to configure this particular token and how it can be, yeah, how it's protected or what restrictions are put on anyone that tries to use this to authenticate with DHS2. For example, the default expiration is 30 days, which means after 30 days this token will stop working. This is a good practice to have when creating new tokens because it means that you can't accidentally forget about one that then gets posted on Twitter or something and then you have anyone with that token can access your server forever unless you notice that somebody is doing something wrong. So if you have expiration dates set on those tokens, you can have some more control over how those tokens can be used to access DHS2. So let's go ahead and set this for seven days. You can also set specific IP addresses with which this token can be used to access DHS2 from which. And that's important for server side scripts because if you add a specific IP address where your integration service is running or some other service that you're talking to, that will prevent this token from being used anywhere else. And that's a big advantage. If you're in a browser context, which again has some security implications, so it's discouraged to use this unless you really know what you're doing, you can also restrict the domain names from which this token can be used. So you can specify the referrers which are allowed to use this particular token. In the server script context and the browser context, you can also specify which HDG methods are allowed. This means whether you can access data or change data in different ways and you can turn that on and off for different tokens. Obviously GET is much safer than being able to create new data or modify existing data or delete data. So being able to just access and read information is an important restriction that you can put on a personal access token, which is not possible or it's more difficult to apply to basic authentication when using the API. Also, this is a very long list in this case, but this will show you exactly which authorities are granted to the current user and will be available to anyone using the personal access token to authenticate against the API. This is quite a long list here, but it will be shorter for most users that you create and the idea is to make this as short as possible because you should be creating a new user for this particular integration that you're building to create basically to restrict the authorities that are granted to that token as much as possible. So if we go ahead and generate this new token, you'll see that we have created a token here. This is a random string that should be unguessable and then you can click copy to clipboard or copy it directly. Importantly, you won't be able to see this again once you move away from this page. So this token will still be available and valid, but after you see it for the first time, you can't see it again and that's a security feature as well. You can delete it, which will remove access to that particular token if you would like. So that's personal access tokens, which are important security feature of the DHS2 API, introduced in 237.0.