If you check the environment, you'll see that the token was stored. Now let's write a second test, a GET, that will use the token. I went through a similar sequence by doing a request for /regions/uy, but I added a line in the headers, with the Authorization key and the Bearer {{token}} value, so that the previously stored token value would be replaced in the header. I also added a couple of tests to make sure (1) I got a successful JSON answer, and (2) the answer was an array of at least 19 regions. (Yes, I know my country, Uruguay, has exactly 19 regions, but sometimes, for test purposes, I may add some new ones!) The tests show some features we haven't seen before:

pm.test("Answer should be JSON", () => {
    pm.response.to.be.success;
    pm.response.to.have.jsonBody(); 
});
 
pm.test("Answer should have at least 19 regions", () => {
    const regions = JSON.parse(pm.response.text());
    pm.expect(regions).to.have.lengthOf.at.least(19);
});

In this fashion, you can create complete sequences of requests; make sure that getting the JWT is placed earlier in the list. In a collection, you can also have many folders, each with a distinct sequence of steps. (You may also change the sequence programatically, but we won't get into that here; check out https://www.getpostman.com/docs/v6/postman/scripts/branching_and_looping for more information.)

I created two folders to test some GETs and a DELETE—but, of course, you should be writing even more tests to verify every method, and as many different sequences as possible. Let's see how we can make them run.