> ## Documentation Index > Fetch the complete documentation index at: https://docs.cocoondata.com/llms.txt > Use this file to discover all available pages before exploring further. # Authentication and authorization All features of Covata technologies are accessed through a *Covata user* account, which is registered on the Covata Platform. For more information about Covata users, refer to the [Administering users within an organization](/3.3/admin-org/administering-users-within-an-organisation.md) page of the [Safe Share Organization Administrator's Guide](/3.3/admin-org.md). In almost all cases, to access resources on the Covata Platform through its API, your application requires a Covata user account that has been authenticated and authorized to the Covata Platform. The accessible resources on the Covata Platform are those to which that Covata user account is permitted to access. ## Working with OAuth 2.0 on the Covata Platform The Covata API utilizes the [OAuth 2.0 Authorization Framework](http://tools.ietf.org/html/rfc6749) to authenticate and authorize Covata user accounts securely to the Covata Platform. The OAuth 2.0 process (or 'dance') to obtain an *access token* (1) using the authorization code *grant type* (2) consists of the following steps: 1. Your (client) application initiates a request for an authorization code from the Covata Platform. \ **Note:** The authorization code is a short string/code, typically alphanumeric, whose purpose is to ensure that this step (and especially the following 2) are connected. 2. A Covata user authenticates themselves to the Covata Platform (directly) and if this is successful, the Covata Platform sends back an authorization code to your application. 3. Your application makes a subsequent request to the Covata Platform to receive an access token. This 2nd request contains the authorization code *and* your application's client credentials. The *authorization code* grant type process for obtaining an access token provides the maximum security features offered by OAuth 2.0, since a Covata user's credentials are not specified directly through your client application and the *client credentials* (3) can be kept as secure as possible (on the proviso that your client application is a server-side web application and properly implements TLS). The Covata API also provides support for the *implicit* and *password* grant types, which are also part of the OAuth 2.0 Authorization Framework. These additional grant types provide authentication/authorization solutions for a wider range of client application types and are simpler processes than that for the authorization code grant type described above. However, both the implicit and password grant types do not possess all the security features provided by the authorization code grant type process. (1) An *access token* defines a set of accessible resources available to a user on the Covata Platform. For more information about Covata Platform *access* and *refresh tokens*, refer to the description of the [Grant types](/3.3/admin-platform/configuring-client-applications.md#grant-types) field on the [Configuring client applications](/3.3/admin-platform/configuring-client-applications.md) page of the Safe Share Administrator's Guide. (2) An OAuth 2.0 *grant type* is a credential representing a Covata user's *authorization* to access that user's protected resources on the Covata Platform. (3) A set of *client credentials* is an identity for your client application and consists of both a [client ID](/3.3/admin-platform/configuring-client-applications.md#client-id) and a [client secret](/3.3/admin-platform/configuring-client-applications.md#client-secret). Client credentials are analogous to user credentials, whereby a username/email address and password (for identifying a person) are equivalent to the client ID and client secret, respectively. The following table lists different client application types and the corresponding OAuth grant types best suited for these application types: | Client application type | Recommended OAuth 2.0 grant types | | - | - | | Server-side web application | Authorization code | | Native desktop/laptop or mobile application | Authorization code \* or Password \* (if the client application was developed by Covata) | | User agent (e.g. client-side application running in a web browser) | Implicit or Authorization code (if you would like your application to use refresh tokens to obtain new access tokens) | | Administrator/system-run service (e.g. Java scheduled job) | Password | \* When deciding on which of these grant types to implement in your client application, the authorization code may provide more security or trust than password, in that a Covata user's credentials are not specified directly through your client application when the user authenticates to the Covata Platform. This grant type decision would most likely amount to the level of trust that parties outside your organization have in your application. ## Registering your application on the Covata Platform Before developing your application, you should consult your Safe Share administrator to begin the process of registering your application on the Covata Platform. After agreeing on the grant type(s) that your application will implement, your Safe Share administrator can proceed with your application's registration process. Once your application is registered, your Safe Share administrator should securely issue you with client credentials (a client ID and client secret) to hard code into your application. These credentials are used to 'authenticate' your application to the Covata Platform. Be aware, however, that if your application is a native desktop/laptop, a mobile or a user agent-based application, then client credentials are less secure than they would be for a server-side web application (with properly implemented TLS). Therefore in these circumstances, your Safe Share administrator may allow you to generate your own client credentials. See [Configuring client applications](/3.3/admin-platform/configuring-client-applications.md) in the Safe Share Administrator's Guide for more information. ## Overview of the OAuth 2.0 process The following steps outline the Covata API OAuth 2.0 process for authenticating and authorizing your application to access a Covata user's resources on the Covata Platform: 1. [Initiating authentication and authorization](/3.3/api/authentication-and-authorisation.md#initiating-authentication-and-authorisation) (initiate the process for obtaining an access token and optional refresh token from the Covata Platform) 2. [Receiving the access token](/3.3/api/authentication-and-authorisation.md#receiving-the-access-token) (the Covata Platform responds with the access token) ## Initiating authentication and authorization The authentication and authorization process begins by initiating appropriate requests to the Covata Platform to obtain an [access token](/3.3/admin-platform/configuring-client-applications.md#grant-types). The nature of these requests differs depending on one of the [three supported OAuth 2.0 grant types](/3.3/api/authentication-and-authorisation.md#client-application-types-and-best-suited-oauth-2-0-grant-types) your application has permission to use: * [Authorization code](/3.3/api/authentication-and-authorisation.md#using-the-authorization-code-grant-type) * [Implicit](/3.3/api/authentication-and-authorisation.md#using-the-implicit-grant-type) * [Password](/3.3/api/authentication-and-authorisation.md#using-the-password-grant-type) Once the authentication and authorization process is successful, an access token is returned to your application. Pass this token in subsequent requests to the Covata Platform to perform other interactions and activities through the Covata API. ### Using the authorization code grant type **Step (1)** To obtain an access token from the Covata Platform using the authorization code grant type, make an initial `GET` method request to this API endpoint: * [\/api/oauth/authorize](/3.3/api/access-service-api-oauth-authorize.md) with the following URL parameters: * `response_type` - Use the value `code` * `client_id` - The client ID of your application's client credentials, which would have been generated when your application was [registered](/3.3/api/authentication-and-authorisation.md#registering-your-application-on-the-platform) on the Covata Platform. * `redirect_uri` - Your application's URL/URI, which will handle the initial response from the Covata Platform that contains the actual authorization code. This initial response is sent after the user has successfully authenticated. The purpose of this request is to begin the process of authenticating a user to the Covata Platform, by presenting the user with the Covata Sign-in page. **Example initial request:** ```bash theme={null} curl https://access-service.xy-company.com/api/oauth/authorize?response_type=code&client_id=exampleClientApplication&redirect_uri=https%3A%2F%2Fmy-application-url%2Fauthcallback \ -X GET ``` **Step (2)** Once the Covata user has successfully authenticated (and if required, has accepted the *application approval* step), the Covata Platform responds by redirecting to your application's URL/URI (i.e. the `redirect_uri` value above) to handle the authorization code, whose value is the `code` URL parameter. **For example:** ```text theme={null} https://my-application-url/authcallback?code=lEQmsFkB02NGPaB3YtaDnA ``` **Step (3)** To complete the authentication and authorization process, your application should make a 2nd request to the Covata Platform to this API endpoint (using the `POST` method): * [\/api/oauth/token](/3.3/api/access-service-api-oauth-token.md) with the following parameters sent as form URL-encoded (i.e. `application/x-www-form-urlencoded`) data in the request's body: * `grant_type` - Use the value `authorization_code` * `code` - The value of the authorization code returned by the the Covata Platform (and initially handled by your application through the redirect URI). * `redirect_uri` - Your application's URL/URI that handled the initial response from the Covata Platform that contained the actual authorization code. This 2nd request requires [HTTP Basic authentication](http://tools.ietf.org/html/rfc1945#section-11.1) specified in its header, whose value is the string value of your application's client ID and client secret (separated by a colon) and encoded with [Base64](https://tools.ietf.org/html/rfc4648). > [!TIP] > > The client ID and client secret values constitute your application's client credentials, which would have been generated when your application was [registered](/3.3/api/authentication-and-authorisation.md#registering-your-application-on-the-platform) on the Covata Platform. For example, encoding: * `exampleClientApplication:exampleClientApplicationSecret` \ with Base64 results in the value: * `ZXhhbXBsZUNsaWVudEFwcGxpY2F0aW9uOmV4YW1wbGVDbGllbnRBcHBsaWNhdGlvblNlY3JldA==` **Example 2nd request:** ```bash theme={null} curl https://access-service.xy-company.com/api/oauth/token \ -H 'Authorization: Basic ZXhhbXBsZUNsaWVudEFwcGxpY2F0aW9uOmV4YW1wbGVDbGllbnRBcHBsaWNhdGlvblNlY3JldA==' \ -d 'grant_type=authorization_code' \ -d 'code=lEQmsFkB02NGPaB3YtaDnA' \ -d 'redirect_uri=https://my-application-url/authcallback' \ -X POST ``` > [!NOTE] > > Submitting a cURL command like the one above with at least one `-d` option results in the following header: \\ > > `Content-Type: application/x-www-form-urlencoded` \\ > > being automatically included in the request. Be aware that this header is required for the request to succeed. The Covata Platform responds with an access token. Continue on to [Receiving the access token](/3.3/api/authentication-and-authorisation.md#receiving-the-access-token) [from authorization code grant type requests](/3.3/api/authentication-and-authorisation.md#from-authorization-code-or-password-grant-type-requests) for details. ### Using the implicit grant type To obtain an access token from the Covata Platform using the implicit grant type, make a single `GET` method request to this API endpoint: * [\/api/oauth/authorize](/3.3/api/access-service-api-oauth-authorize.md) with the following URL parameters: * `response_type` - Use the value `token` * `client_id` - The client ID of your application's client credentials, which would have been generated when your application was [registered](/3.3/api/authentication-and-authorisation.md#registering-your-application-on-the-platform) on the Covata Platform. * `redirect_uri` - Your application's URL/URI, which will handle the response from the Covata Platform that contains the access token itself. This response is sent after the user has successfully authenticated. The purpose of this request is to begin the process of authenticating a user to the Covata Platform, by presenting the user with the Covata Sign-in page, which if successful, results in the direct retrieval of the access token. **Example request:** ```bash theme={null} curl https://access-service.xy-company.com/api/oauth/authorize?response_type=token&client_id=exampleClientApplication&redirect_uri=https%3A%2F%2Fmy-application-url%2Fauthcallback \ -X GET ``` Once the Covata user has successfully authenticated, the Covata Platform responds with an access token. Continue on to [Receiving the access token](/3.3/api/authentication-and-authorisation.md#receiving-the-access-token) [from implicit grant type requests](/3.3/api/authentication-and-authorisation.md#from-implicit-grant-type-requests) for details. ### Using the password grant type To obtain an access token from the Covata Platform using the password grant type, simply make a single `POST` method request to this API endpoint: * [\/api/oauth/token](/3.3/api/access-service-api-oauth-token.md) with the following parameters sent as form URL-encoded (i.e. `application/x-www-form-urlencoded`) data in the request's body: * `grant_type` - Use the value `password` * `username` - The email address of a Covata user's credentials (acquired through your application). * `password` - The password of a Covata user's credentials (acquired through your application). Like [above](/3.3/api/authentication-and-authorisation.md#using-the-authorization-code-grant-type), this request requires [HTTP Basic authentication](http://tools.ietf.org/html/rfc1945#section-11.1) specified in its header, whose value is the string value of your application's client ID and client secret (separated by a colon) and encoded with [Base64](https://tools.ietf.org/html/rfc4648). > [!TIP] > > The client ID and client secret values constitute your application's client credentials, which would have been generated when your application was [registered](/3.3/api/authentication-and-authorisation.md#registering-your-application-on-the-platform) on the Covata Platform. For example, encoding: * `exampleClientApplication:exampleClientApplicationSecret` \ with Base64 results in the value: * `ZXhhbXBsZUNsaWVudEFwcGxpY2F0aW9uOmV4YW1wbGVDbGllbnRBcHBsaWNhdGlvblNlY3JldA==` **Example request:** ```bash theme={null} curl https://access-service.xy-company.com/api/oauth/token \ -H 'Authorization: Basic ZXhhbXBsZUNsaWVudEFwcGxpY2F0aW9uOmV4YW1wbGVDbGllbnRBcHBsaWNhdGlvblNlY3JldA==' \ -d 'grant_type=password' \ --data-urlencode 'username=alex.originator@xy-company.com' \ --data-urlencode 'password=password1' \ -X POST ``` > [!NOTE] > > Submitting a cURL command like the one above with at least one `-d` option results in the following header: \\ > > `Content-Type: application/x-www-form-urlencoded` \\ > > being automatically included in the request. Be aware that this header is required for the request to succeed. The Covata Platform responds with an access token. Continue on to [Receiving the access token](/3.3/api/authentication-and-authorisation.md#receiving-the-access-token) [from password grant type requests](/3.3/api/authentication-and-authorisation.md#from-authorization-code-or-password-grant-type-requests) for details. ## Receiving the access token ### From authorization code or password grant type requests Once the [authentication and authorization processes](/3.3/api/authentication-and-authorisation.md#initiating-authentication-and-authorisation) for either the [authorization code](/3.3/api/authentication-and-authorisation.md#using-the-authorization-code-grant-type-step-3) or [password](/3.3/api/authentication-and-authorisation.md#using-the-password-grant-type) grant type above is successful (via the final `POST` method request to the [\/api/oauth/token](/3.3/api/access-service-api-oauth-token.md) API endpoint), the Covata Platform responds with an access token in the body of the response (as a [JSON](http://json.org/) object) as well as a refresh token (if your registered client application on the Covata Platform has been configured to issue one). **Example response:** ```json theme={null} { "access_token": "eyJhbGciOiJSUzI1NiJ9.eyJleHAiOjE0NjcwMTY2NjYsInVzZXJfbmFtZSI6ImFsZXgub3JpZ2luYXRvckB4eS1jb21wYW55LmNvbSIsImF1dGhvcml0aWVzIjpbIlBFUk1fRklMRV9ERUxFVEUiLCJQRVJNX0FQUF9BUFBST1ZBTF9SRVZPS0UiLCJQRVJNX1ZJRVciLCJQRVJNX1VTRVJJTkZPX0dFVF9OT1RJRllfUFJFRiIsIlBFUk1fUFJJTlQiLCJQRVJNX0FQSV9WMV9BQ0NFU1MiLCJQRVJNX1NFTEZfUkVWT0tFX1RPS0VOUyIsIlBFUk1fTU9WRSIsIlBFUk1fVVNFUklORk9fR0VUU0VMRiIsIlBFUk1fUkVOQU1FIiwiUEVSTV9BUElfT0FVVEhfQUNDRVNTIiwiUEVSTV9WSUVXX09USEVSIiwiUEVSTV9ERVZJQ0VfQVVUSEVOVElDQVRJT04iLCJQRVJNX0ZJTEVfQUREIiwiUEVSTV9DT05UQUNUU19MSVNUIiwiUEVSTV9GT0xERVJfQUREIiwiUEVSTV9VU0VSSU5GT19FRElUX05PVElGWV9QUkVGIiwiUEVSTV9GT0xERVJfREVMRVRFIiwiUk9MRV9PUklHSU5BVE9SIiwiUEVSTV9PQVVUSF9UT0tFTl9SRVZPS0UiLCJQRVJNX1NFTkRfSVRFTV9OT1RJRklDQVRJT04iLCJQRVJNX1NIQVJFIiwiUEVSTV9BUElfQUNDT1VOVF9BQ0NFU1MiLCJQRVJNX0RPV05MT0FEIiwiUEVSTV9DT05UQUNUU19VUERBVEUiLCJQRVJNX0xBQkVMX0xJU1QiLCJQRVJNX0FQUF9BUFBST1ZBTF9MSVNUIiwiUEVSTV9PUkdBTklTQVRJT05fR0VUU0VMRiIsIlBFUk1fT0FVVEhfVE9LRU5fTElTVF9CWV9DTElFTlQiLCJQRVJNX0FQSUNMSUVOVF9BREQiLCJQRVJNX0FQSUNMSUVOVF9MSVNUIiwiUEVSTV9ERUxFVEVfT1RIRVIiLCJQRVJNX09BVVRIX1RPS0VOX0xJU1QiLCJQRVJNX0FERFJFU1NCT09LX0xJU1QiLCJQRVJNX0NPUFkiLCJQRVJNX0NPTlRBQ1RTX0NSRUFURSIsIlBFUk1fUkVNT1ZFX1NFTEYiLCJQRVJNX0NPTlRBQ1RTX0RFTEVURSIsIlBFUk1fVVNFUklORk9fVVBEQVRFIl0sImp0aSI6ImYxY2Q4NGVhLWM2ZTgtNDc4OC04NzliLTEzZDM0ZDQ0ZDUyNiIsImNsaWVudF9pZCI6ImV4YW1wbGVDbGllbnRBcHBsaWNhdGlvbiIsInNjb3BlIjpbIlNDT1BFX09BVVRIX1RPS0VOX0xJU1QiLCJTQ09QRV9DT05UQUNUU19MSVNUIiwiU0NPUEVfT0FVVEhfVE9LRU5fUkVWT0tFIiwiU0NPUEVfRklMRV9ERUxFVEUiLCJTQ09QRV9GSUxFX0FERCIsIlNDT1BFX0ZPTERFUl9BREQiLCJTQ09QRV9BUElfVjFfQUNDRVNTIiwiU0NPUEVfQVBJQ0xJRU5UX0FERCIsIlNDT1BFX1NFTkRfSVRFTV9OT1RJRklDQVRJT04iLCJTQ09QRV9VU0VSSU5GT19FRElUX05PVElGWV9QUkVGIiwiU0NPUEVfREVWSUNFX0FVVEhFTlRJQ0FUSU9OIiwiU0NPUEVfQ09OVEFDVFNfVVBEQVRFIiwiU0NPUEVfRk9MREVSX0RFTEVURSIsIlNDT1BFX01PVkUiLCJTQ09QRV9PQVVUSF9UT0tFTl9MSVNUX0JZX0NMSUVOVCIsIlNDT1BFX1JFTU9WRV9TRUxGIiwiU0NPUEVfU0VMRl9SRVZPS0VfVE9LRU5TIiwiU0NPUEVfVklFVyIsIlNDT1BFX0NPTlNPTEVfQURNSU5fQUNDRVNTIiwiU0NPUEVfQVBJQ0xJRU5UX0xJU1QiLCJTQ09QRV9BRERSRVNTQk9PS19MSVNUIiwiU0NPUEVfU0hBUkUiLCJTQ09QRV9VU0VSSU5GT19VUERBVEUiLCJTQ09QRV9BQ0xfQURNSU4iLCJTQ09QRV9DT05UQUNUU19ERUxFVEUiLCJTQ09QRV9BUFBfQVBQUk9WQUxfUkVWT0tFIiwiU0NPUEVfUFJJTlQiLCJTQ09QRV9VU0VSSU5GT19HRVRfTk9USUZZX1BSRUYiLCJTQ09QRV9WSUVXX09USEVSIiwiU0NPUEVfUkVOQU1FIiwiU0NPUEVfQ09OVEFDVFNfQ1JFQVRFIiwiU0NPUEVfREVMRVRFX09USEVSIiwiU0NPUEVfQVBJX09BVVRIX0FDQ0VTUyIsIlNDT1BFX0RPV05MT0FEIiwiU0NPUEVfQVBQX0FQUFJPVkFMX0xJU1QiLCJTQ09QRV9VU0VSSU5GT19HRVRTRUxGIiwiU0NPUEVfQ09QWSJdfQ.XMEGyBnYEfy8dAPnJhchYlSJGreBRYGN1KbSF4DZoM6aegIPuSd-hES-nDH56ErrY-xLoMnrWYNeBKEE-Z1eJ6Y2qTnUexebWe7FMcqlVDRSKKQHw2pvcchRMuET3DibxwMZv-JwYcgb1npOWQL5ESRD38k-4kKoVfLfmStkm3kGuPsOr7db2kj6mQF8eMuvXjplzUMU2o42YdgBxLQ0jPcN-FM9yGxFJhWqZ_u6J45Fjlcc1SNYtgQZbwdd4IhfuBtLXqfeEVnNA7gRuNBwsEgBqx3G-i1xtu7ibt8i382JBO0gNmkxxPEK-E5tys-0EwOEv1i42_EYX7nBKd5i5A", "token_type": "bearer", "refresh_token": "75605643-a194-4bfc-a379-0d0154ab9783", "jti": "f1cd84ea-c6e8-4788-879b-13d34d44d526" } ``` ### From implicit grant type requests Once the [authentication and authorization process](/3.3/api/authentication-and-authorisation.md#initiating-authentication-and-authorisation) for the [implicit grant type](/3.3/api/authentication-and-authorisation.md#using-the-implicit-grant-type) above is successful (via the `GET` method request to the [\/api/oauth/authorize](/3.3/api/access-service-api-oauth-authorize.md) API endpoint), the Covata Platform responds by redirecting to your application's URL/URI (i.e. the `redirect_uri` value above) with an access token as a URL parameter (amongst other parameters). **Example response:** ```text theme={null} https://my-application-url/authcallback&access_token=eyJhbGciOiJSUzI1NiJ9.eyJleHAiOjE0NjcwMTY2NjYsInVzZXJfbmFtZSI6ImFsZXgub3JpZ2luYXRvckB4eS1jb21wYW55LmNvbSIsImF1dGhvcml0aWVzIjpbIlBFUk1fRklMRV9ERUxFVEUiLCJQRVJNX0FQUF9BUFBST1ZBTF9SRVZPS0UiLCJQRVJNX1ZJRVciLCJQRVJNX1VTRVJJTkZPX0dFVF9OT1RJRllfUFJFRiIsIlBFUk1fUFJJTlQiLCJQRVJNX0FQSV9WMV9BQ0NFU1MiLCJQRVJNX1NFTEZfUkVWT0tFX1RPS0VOUyIsIlBFUk1fTU9WRSIsIlBFUk1fVVNFUklORk9fR0VUU0VMRiIsIlBFUk1fUkVOQU1FIiwiUEVSTV9BUElfT0FVVEhfQUNDRVNTIiwiUEVSTV9WSUVXX09USEVSIiwiUEVSTV9ERVZJQ0VfQVVUSEVOVElDQVRJT04iLCJQRVJNX0ZJTEVfQUREIiwiUEVSTV9DT05UQUNUU19MSVNUIiwiUEVSTV9GT0xERVJfQUREIiwiUEVSTV9VU0VSSU5GT19FRElUX05PVElGWV9QUkVGIiwiUEVSTV9GT0xERVJfREVMRVRFIiwiUk9MRV9PUklHSU5BVE9SIiwiUEVSTV9PQVVUSF9UT0tFTl9SRVZPS0UiLCJQRVJNX1NFTkRfSVRFTV9OT1RJRklDQVRJT04iLCJQRVJNX1NIQVJFIiwiUEVSTV9BUElfQUNDT1VOVF9BQ0NFU1MiLCJQRVJNX0RPV05MT0FEIiwiUEVSTV9DT05UQUNUU19VUERBVEUiLCJQRVJNX0xBQkVMX0xJU1QiLCJQRVJNX0FQUF9BUFBST1ZBTF9MSVNUIiwiUEVSTV9PUkdBTklTQVRJT05fR0VUU0VMRiIsIlBFUk1fT0FVVEhfVE9LRU5fTElTVF9CWV9DTElFTlQiLCJQRVJNX0FQSUNMSUVOVF9BREQiLCJQRVJNX0FQSUNMSUVOVF9MSVNUIiwiUEVSTV9ERUxFVEVfT1RIRVIiLCJQRVJNX09BVVRIX1RPS0VOX0xJU1QiLCJQRVJNX0FERFJFU1NCT09LX0xJU1QiLCJQRVJNX0NPUFkiLCJQRVJNX0NPTlRBQ1RTX0NSRUFURSIsIlBFUk1fUkVNT1ZFX1NFTEYiLCJQRVJNX0NPTlRBQ1RTX0RFTEVURSIsIlBFUk1fVVNFUklORk9fVVBEQVRFIl0sImp0aSI6ImYxY2Q4NGVhLWM2ZTgtNDc4OC04NzliLTEzZDM0ZDQ0ZDUyNiIsImNsaWVudF9pZCI6ImV4YW1wbGVDbGllbnRBcHBsaWNhdGlvbiIsInNjb3BlIjpbIlNDT1BFX09BVVRIX1RPS0VOX0xJU1QiLCJTQ09QRV9DT05UQUNUU19MSVNUIiwiU0NPUEVfT0FVVEhfVE9LRU5fUkVWT0tFIiwiU0NPUEVfRklMRV9ERUxFVEUiLCJTQ09QRV9GSUxFX0FERCIsIlNDT1BFX0ZPTERFUl9BREQiLCJTQ09QRV9BUElfVjFfQUNDRVNTIiwiU0NPUEVfQVBJQ0xJRU5UX0FERCIsIlNDT1BFX1NFTkRfSVRFTV9OT1RJRklDQVRJT04iLCJTQ09QRV9VU0VSSU5GT19FRElUX05PVElGWV9QUkVGIiwiU0NPUEVfREVWSUNFX0FVVEhFTlRJQ0FUSU9OIiwiU0NPUEVfQ09OVEFDVFNfVVBEQVRFIiwiU0NPUEVfRk9MREVSX0RFTEVURSIsIlNDT1BFX01PVkUiLCJTQ09QRV9PQVVUSF9UT0tFTl9MSVNUX0JZX0NMSUVOVCIsIlNDT1BFX1JFTU9WRV9TRUxGIiwiU0NPUEVfU0VMRl9SRVZPS0VfVE9LRU5TIiwiU0NPUEVfVklFVyIsIlNDT1BFX0NPTlNPTEVfQURNSU5fQUNDRVNTIiwiU0NPUEVfQVBJQ0xJRU5UX0xJU1QiLCJTQ09QRV9BRERSRVNTQk9PS19MSVNUIiwiU0NPUEVfU0hBUkUiLCJTQ09QRV9VU0VSSU5GT19VUERBVEUiLCJTQ09QRV9BQ0xfQURNSU4iLCJTQ09QRV9DT05UQUNUU19ERUxFVEUiLCJTQ09QRV9BUFBfQVBQUk9WQUxfUkVWT0tFIiwiU0NPUEVfUFJJTlQiLCJTQ09QRV9VU0VSSU5GT19HRVRfTk9USUZZX1BSRUYiLCJTQ09QRV9WSUVXX09USEVSIiwiU0NPUEVfUkVOQU1FIiwiU0NPUEVfQ09OVEFDVFNfQ1JFQVRFIiwiU0NPUEVfREVMRVRFX09USEVSIiwiU0NPUEVfQVBJX09BVVRIX0FDQ0VTUyIsIlNDT1BFX0RPV05MT0FEIiwiU0NPUEVfQVBQX0FQUFJPVkFMX0xJU1QiLCJTQ09QRV9VU0VSSU5GT19HRVRTRUxGIiwiU0NPUEVfQ09QWSJdfQ.XMEGyBnYEfy8dAPnJhchYlSJGreBRYGN1KbSF4DZoM6aegIPuSd-hES-nDH56ErrY-xLoMnrWYNeBKEE-Z1eJ6Y2qTnUexebWe7FMcqlVDRSKKQHw2pvcchRMuET3DibxwMZv-JwYcgb1npOWQL5ESRD38k-4kKoVfLfmStkm3kGuPsOr7db2kj6mQF8eMuvXjplzUMU2o42YdgBxLQ0jPcN-FM9yGxFJhWqZ_u6J45Fjlcc1SNYtgQZbwdd4IhfuBtLXqfeEVnNA7gRuNBwsEgBqx3G-i1xtu7ibt8i382JBO0gNmkxxPEK-E5tys-0EwOEv1i42_EYX7nBKd5i5A&token_type=bearer&scope=&jti=f1cd84ea-c6e8-4788-879b-13d34d44d526 ``` This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.