The first option is to add a header. Under the Headers tab, add a key called Authorization with the value Bearer <your-jwt-token>. Use the double curly brace syntax to swap in your token’s variable value.
If your authorization accepts a custom syntax, you can manually tweak the prefix here (e.g. Token <your-access-token> instead of Bearer <your-access-token).
The second option is to use an authorization helper. Under the Authorization tab, select the Bearer Token authorization type. Use the double curly brace syntax to swap in your token’s variable value.
Click the orange Preview Request button to see a temporary header has been added under the Headers tab. This temporary header is not saved with your request or collection.
What’s the difference between these 2 approaches? The approach you use should depend on how you’re planning to use it.
With both of these options, you can share the request and collection with your teammates. Header is saved with the request and collection under the header property.
Can set authorization at the collection-, folder-, or request-level. Easy to set up the same authorization method for every request inside the collection or folder.
With both of these options, you can share the request and collection with your teammates. Authorization is saved under the auth property.
Option 1: Separate request at the beginning of the collection
This option is ideal if you’re working with a small collection that runs quickly, or you have a long-lived token that is not likely to expire by the end of the
. In this case, create an initial request at the beginning of the collection to retrieve and store the token. You can use the same token value throughout the remainder of your collection run.
Option 2: Pre-request script to run before each request
This option is good if you’re working with a large collection that might take a while to run, or you have a short-lived token that could expire soon. In this case, add some logic in a
) and then reset your new token’s time to live. With this approach, remember that you can use a collection- or folder-level script to run this check prior to every request in the collection or folder.
Say that you saved your JWT as a Postman environment variable, and you shared the environment with your teammates because you’re collaborating on a project. Can you keep stuff private, so that your teammates don’t have access to it?
are an additional layer within the Postman app that stores variable values locally. By default, sessions do not sync with Postman servers. Changes captured in the individual session remain local to your Postman instance, unless you explicitly sync to the cloud.
Go to your Settings, and toggle off “Automatically persist variable values”.
Now when you send a request and set a variable, the CURRENT VALUE is populated. You can think of this as a value that’s stored in a local session.
If you want to share this value with your teammates or sync it to the Postman servers, this requires another step to to explicitly sync to the cloud. To sync all of your Current Values to the Initial Values, click Persist All. To sync only a single Current Value to the Initial Value, copy and paste the value from the 3rd column to the second column.
Session variables allow you to reuse data and keep it secure while working in a collaborative environment. They allow you more granular control over syncing to the server or sharing information with your teammates. Learn more about