---
title: "Migrating to Authorization Header"
slug: "migrating-to-authorization-header"
updated: 2024-10-24T16:39:56Z
published: 2024-10-24T16:39:56Z
canonical: "learn.servitly.com/migrating-to-authorization-header"
---

> ## Documentation Index
> Fetch the complete documentation index at: https://learn.servitly.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Migrating to Authorization Header

To be compliant with the Chrome's upcoming limitations regarding the use of [third-party cookies](https://developers.google.com/privacy-sandbox/3pcd#report-issues), the JWT token will be also returned into the body of the login API response, and it must be sent back inside the *Authorization* header as a bearer token.

Note that the old cookie-based mechanism will continue to operate until the end of 2024.

Here is the new login response body:

```json
{
 "token": "eyJhbGciOiJIUzUxMiJ9.eyJsYXN0TG9naW5Ua********",
 "refreshToken": "2f2c67a7-8c41-479b-b6ff-*****",
 "userId": "964ca322a6129f463ad55ee3",
 "tenantId": "961539a889504796e231d68b"
}
```

Into the new response body, you can find the *token* that must be stored locally by the client, and the *refreshToken* that you can use, along the *userId and tenantId*, to obtain a new JWT token.

Each authenticated request must include the Authorization header as below:

```http
Authorization: Bearer eyJhbGciOiJIUzUxMiJ9.eyJsYXN0TG9naW5Ua********
```

In the API key declaration, you can specify whether the client should exchange the JWT token via cookies; by default, this option is disabled for new API keys, so it is suggested to start using the Authorization header instead.