Introduction

Home / Sending requests

Getting started

Sending requests
Authorizing requests
Building requests APIs use authorization to ensure that client requests access data securely. This can
involve authenticating the sender of a request and confirming that they have permission to
Authorizing requests
access or manipulate the relevant data. If you're building an API, you can choose from a
Receiving responses variety of auth models. If you're integrating a third-party API, the required authorization will
be specified by the API provider.
Grouping requests in collections

Using variables You can pass auth details along with any request you send in Postman. Auth data can be
included in the header, body, or as parameters to a request. If you enter your auth details
Managing environments
in the Authorization tab, Postman will automatically populate the relevant parts of the
Visualizing responses request for your chosen auth type. You can use variables and collections to define
authorization details more safely and efficiently, enabling you to reuse the same
Specifying examples
information in multiple places.

Contents
Using cookies

Working with certificates

Generating client code Specifying authorization details

Troubleshooting requests
Authentication for public APIs
Capturing request data
Inheriting auth
Querying with GraphQL
 Using gRPC requests Authorization types

Using WebSocket requests

No auth
Using SOAP requests
API key
Writing scripts
Bearer token
Using collections

JWT bearer
Using Postman Flows

Using the Postman CLI Basic auth

Collaborating in Postman Digest auth

Designing and developing your API

OAuth 1.0
Documenting your API
OAuth 2.0
Monitoring your API

Authorization code
API Governance

Administration Authorization code (with PKCE)

Using reports
Implicit

Developer resources
Password credentials
Integrations
Client credentials

Requesting an OAuth 2.0 token

Refreshing an OAuth 2.0 token

 Sharing an OAuth 2.0 token

Changing the OAuth 2.0 token type

Hawk authentication

AWS Signature

NTLM authentication

Akamai EdgeGrid

Syncing cookies

Troubleshooting

Specifying authorization details

With a request open in Postman, use the Authorization tab to select an auth type, then
complete the relevant details for your selected type. The correct data values will be
determined by your API at the server side. If you're using a third party API, refer to the
provider's documentation for any required auth details.

Easier API authentication is available for certain public APIs. For more information,
see Authentication for public APIs.
 You can use these auth types with Newman and monitors as well as in Postman.

When you select a type from the Type dropdown list, Postman will indicate which parts of
the request your details will be included in, for example the header, body, URL, or query
parameters. Postman adds your auth details to the relevant parts of the request when you
select or enter them, so you can preview how your data will be sent before you run the
request.

Your auth data will appear in the relevant parts of the request, for example in the Headers
tab. To show headers that were added automatically, select hidden.
Hover over a header to get information about where it was added. To change an auth
header, return to the Authorization tab and update your configuration.

You can't override headers added by your Authorization selections directly in the
Headers tab. If you need different auth headers from those autogenerated by
Postman, alter your setup in Authorization, or remove your auth setup and add
headers manually.

Your request auth can use environment, collection, and global variables. Postman doesn't
save header data or query parameters to avoid exposing sensitive data such as API keys.

You can inspect a raw dump of the entire request including auth data in the Postman
Console after you send it.

Authentication for public APIs

An increasing number of public APIs offer easier authentication through Postman, including
Stripe, Open AI, Notion, and Spotify. When you create a request to a supported API,
Postman will automatically recognize if the API requires authentication and give you the
option to Set up new authorization.

Select Set up new authorization to learn what authentication credentials you'll need to
make your request and where you can find them. For APIs that support OAuth 2.0, you
can select Authorize to complete authorization. For APIs requiring credentials like tokens
or API keys, you can paste those directly into your request.
If you're an API publisher, you can join the waitlist to provide easier authentication for your
public APIs to the Postman community. To do so, open Postman and select Team in the
upper right, then Team Settings > Set Up API authorization. Alternatively, select API
Network from the Postman header, then select Public API Network > Set up API
authorization.

Inheriting authorization
If you group your requests in collections and folders, you can specify auth details to reuse
throughout a group.

By default, requests inside the collection or folder will inherit auth from the parent, which
means that they'll use the same auth that you've specified at the folder or collection level.
To change this for an individual request, make a different selection in the request
Authorization tab.

Authorization types
Select a type from the Type dropdown list on the Authorization tab. You can choose an
authorization type on requests, collections, or folders.

No auth
Postman won't send authorization details with a request unless you specify an auth type. If
your request doesn't require authorization, select No Auth from the Authorization tab Type
dropdown list.

API key
With API key auth, you send a key-value pair to the API either in the request headers or
query parameters. In the request Authorization tab, select API Key from the Type list.
Enter your key name and value, and select either Header or Query Params from the Add
to dropdown list. You can store your values in variables for extra security.
Postman will append the relevant information to your request Headers or the URL query
string.
Bearer token
Bearer tokens enable requests to authenticate using an access key, such as a JSON Web
Token (JWT). The token is a text string, included in the request header. In the request
Authorization tab, select Bearer Token from the Type dropdown list. In the Token field,
enter your API key value. For added security, store it in a variable and reference the
variable by name.

Postman will append the token value to the text Bearer in the required format to the
request Authorization header as follows:

Bearer <Your API key>

If a custom prefix is needed, use an API Key with a key of Authorization.

JWT bearer
Postman also supports generating JWT bearer tokens to authorize requests. You can enter
a payload in an editor, and JWT tokens are generated and added to the request. In the
request Authorization tab, select JWT Bearer from the Type dropdown list.

Add JWT token to - Select Request Header or Query Param to specify how the
JWT token will be added to your request.

Algorithm - Select an algorithm to use for the JWT token. Supported algorithms
include:

HS - HMAC with SHA

 RS - RSA (RSASSA-PKCS1-v1_5) with SHA

ES - ECDSA with SHA

PS - RSA (RSASSA-PSS) with SHA

Secret - The secret that’s used with the HMAC-SHA algorithm.

Secret Base64 encoded - If the secret is encoded in the base-64 format.

Private key - The private key for signing the token for RS, ES, and PS algorithms.
Select Select file to upload a private key in PKCS #8 format.

Payload - Enter the payload data for your JWT token, in JSON format.

In the Advanced configuration section, you can also configure the following items. If you
don't configure them, they are generated automatically.

Header prefix - An optional prefix to use at the start of headers. This header prefix
is part of the request and not a part of JWT.

Headers - Any custom headers you also want to send in the JWT token. Headers
pertaining to the selected algorithm are automatically added.

Basic auth
Basic authentication involves sending a verified username and password with your request.
In the request Authorization tab, select Basic Auth from the Type dropdown list.
Enter your API username and password in the Username and Password fields. For extra
security, store these in variables.

In the request Headers, the Authorization header passes the API a Base64 encoded string
representing your username and password values, appended to the text Basic as follows:

Basic <Base64 encoded username and password>

Digest auth
With Digest auth, the client sends a first request to the API, and the server responds with
a few details, including a number that can be used only once (a nonce), a realm value,
and a 401 unauthorized response. You then send back an encrypted array of data
including a username and password combined with the data received from the server in
the first request. The server uses the passed data to generate an encrypted string and
compares it against what you sent to authenticate your request.

In the Authorization tab for a request, select Digest Auth from the Type dropdown list.
Postman will present fields for both stages of authentication request. It will autocomplete
the fields for the second request in the Advanced section using data returned from the
server by the first request. To enable Postman to automate the flow, enter Username and
Password values (or variables) and these will be sent with the second request.

If you don't want Postman to automatically extract the data, select Yes, disable
retrying the request in the left column. If you do this, you will need to complete the
advanced fields and run each request manually.
Setting the fields in the Advanced section is optional. Postman will populate them
automatically when your first request runs.

Realm - A string specified by the server in the WWW-Authenticate response

header.

Nonce - A unique string specified by the server in the WWW-Authenticate

response header.

Algorithm - A string that indicates a pair of algorithms used to produce the digest
and a checksum. Postman supports MD5 and SHA algorithms.

qop - The quality of protection applied to the message. The value must be one of
the options specified by the server in the WWW-Authenticate response header.

Nonce Count - The hexadecimal count of the number of requests (including the
current request) that the client has sent with the nonce value in this request.

Client Nonce - An opaque quoted string value provided by the client, used by both
client and server to avoid chosen plaintext attacks, to provide mutual authentication,
and to provide some message integrity protection.

Opaque - A string of data specified by the server in the WWW-Authenticate

response header, which will be used unchanged with URIs in the same protection
space.

OAuth 1.0
OAuth 1.0 enables client applications to access data provided by a third-party API. For
example, as a user of a service, you can grant another application access to your data
with that service without exposing details like your username and password. Accessing
user data with OAuth 1.0 involves a few requests back and forth between client
application, user, and service provider.

OAuth 1.0 is sometimes referred to as "two-legged" (auth only between client and server)
or "three-legged" (where a client requests data for a user of a third-party service). An
example OAuth 1.0 flow could run as follows:

To request user data with a third-party service, a consumer (client application)

requests an access token using credentials such as a key and secret.

The service provider issues an initial token (that doesn't provide access to user
data) and the consumer requests authorization from the user.

When the user grants auth, the consumer makes a request to exchange the
temporary token for an access token, passing verification from the user auth.

The service provider returns the access token and the consumer can then make
requests to the service provider to access the user's data.

Postman supports OAuth Core 1.0 Revision A.

To use OAuth 1.0, do the following:

1. In the Authorization tab for a request, select OAuth 1.0 from the Type dropdown
list.

2. Select a Signature Method from the dropdown list. This will determine which
parameters to include with your request. Postman supports HMAC-SHA1, HMAC-
 SHA256 , HMAC-SHA512 , RSA-SHA1 , RSA-SHA256 , RSA-SHA512 , and
PLAINTEXT.

If your server requires an HMAC or PLAINTEXT signature, Postman will

provide Consumer Key, Consumer Secret, Access Token, and Token Secret
fields.

If you're using an RSA signature, Postman will present Consumer Key, Access
Token, and Private Key inputs.

3. You can optionally set advanced details—otherwise Postman will try to

autocomplete these.

4. You can include the auth details either in the request headers or in the body / URL.
Select one from the Add authorization to dropdown list. Open the Headers or Body
tab if you want to check how the details will be included with the request.

If you send the OAuth 1.0 data in the headers, an Authorization header sending your key
and secret values is appended to the string OAuth together with additional comma-
separated required details.

Postman will append the OAuth 1.0 information to the request Headers when you
have completed all required fields in your Authorization setup.

If you send the OAuth 1.0 data in the body and URL, the data is added either in the
request Body or Parameters depending on the request method.

If the request method is POST or PUT , and if the request body type is x-www-form-
urlencoded , Postman will add the authorization parameters to the request body.
Otherwise, for example in a GET request, your key and secret data will be passed in the
URL query parameters.

The OAuth 1.0 auth parameter values are as follows:

Signature Method - The method your API uses to authenticate requests.

Consumer Key - A value used to identify a consumer with the service provider.

Consumer Secret - A value used by the consumer to establish ownership of the

key. (For HMAC and PLAINTEXT signing methods.)

Access Token - A value representing the consumer's permission to access the

user's data.

Token Secret - A value used by the consumer to establish ownership of a given

token. (For HMAC and PLAINTEXT signing methods.)

Private Key - A private key to generate the auth signature. (For RSA signing
methods.)

Advanced Parameters:

Callback URL - URL service provider will redirect to following user

authorization. (Required if your server uses OAuth 1.0 Revision A.)

Verifier - Verification code from service provider after user auth.

Time Stamp - The timestamp the server uses to prevent replay attacks outside
the time window.
 Nonce - A random string generated by the client.

Version - The version of the OAuth authentication protocol (1.0).

Realm - A string specified by the server in the WWW-Authenticate response

header.

Include body hash - Hash for integrity check with request bodies other than
application/x-www-form-urlencoded . (Deactivated when you're using
callback URL / verifier.)

If your server implementation of OAuth 1.0 requires it, select Add empty parameters
to signature.

You can also select the checkbox to Encode the parameters in the authorization
header for your request.

OAuth 2.0
With OAuth 2.0, you first retrieve an access token for the API, then use that token to
authenticate future requests. Access tokens are typically short-lived, but the authorization
server can also provide a long-lived refresh token. A client application can use the refresh
token to automatically refresh the access token.

Accessing data with OAuth 2.0 varies greatly between API service providers, but typically
involves a few requests back and forth between client application, user, and API. An
example OAuth 2.0 flow could run as follows:

A client application makes a request for the user to authorize access to their data.
 If the user grants access, the application then requests an access token from the
service provider, passing the access grant from the user and authentication details
to identify the client.

The service provider validates these details and returns a short-lived access token
and a long-lived refresh token.

The client uses the access token to request the user data with the service provider.

When the access token expires, the client can use the refresh token to
automatically request a new access token.

To use OAuth 2.0, do the following:

1. In the Authorization tab for a collection or request, select OAuth 2.0 from the Type
dropdown list. Specify if you want pass the auth details in the request URL or
headers.

By default Postman will append the access token to Bearer in the

Authorization header for your request, but if your server implementation
requires a different prefix, you can specify it in the Header Prefix field.

2. To request an access token, fill out the fields in the Configure New Token section,
and select Get New Access Token. To use the token with your request or collection,
select Proceed and then select Use token. The details you used to generate the
token are saved with your request or collection. You can also share the token so
that others with access to the collection can use the token.
 Once you have a token value generated and added, it will appear in the
request Headers.

3. Enter the details for your client application, and any auth details from the service
provider. This allows you to replicate your application auth flow inside Postman to
test authenticated requests.

You can share token credentials with your team. Turn on the Share token
toggle and then select Sync Token. By default Postman won't sync your
token in case you don't want to share it.

4. Postman will prompt you to supply specific details depending on the OAuth 2.0
Grant Type, which can be Authorization code, Implicit, Password credentials, or
Client credentials.

Authorization code
Authorization code grant type requires the user to authenticate with the provider—an
authorization code is then sent back to the client app, extracted, and exchanged with the
provider for an access token to authenticate later requests.

To use authorization code grant type, enter a Callback URL for your client application
(which needs to be registered with the API provider), together with various details provided
by the API service including Auth URL, Access Token URL, Client ID, and Client Secret.

If you are using the Postman desktop app, you can enter your auth details in your
web browser instead of in Postman by selecting Authorize using browser.
Authorization code (with PKCE)
You can use PKCE (Proof Key for Code Exchange) with OAuth 2.0. When you select
Authorization Code (With PKCE) two more fields will become available for Code Challenge
Method and Code Verifier. You can opt to use SHA-256 or Plain algorithms to generate
the code challenge. The verifier is an optional 43-128 character string to connect the
authorization request to the token request.

Authorization code (With PKCE) grant type coupled with Authorize using browser is
recommended to prevent auth code interception attacks.

Implicit
Implicit grant type returns an access token to the client without requiring the extra auth
code step (and is therefore less secure).

To use implicit grant type with your requests in Postman, enter a Callback URL you have
registered with the API provider, the provider Auth URL, and a Client ID for the app you
have registered.

If you are using the Postman desktop app, you can enter your auth details in your
web browser instead of in Postman by selecting Authorize using browser.

Password credentials
OAuth 2.0 Password grant type involves sending username and password directly from the
client and is therefore not recommended if you're dealing with third-party data.

To use password grant type, enter your API provider's Access Token URL, together with
the Username and Password. In some cases you will also need to provide a client ID and
secret.

Client credentials
Client credentials grant type is typically not used to access user data but instead for data
associated with the client application.

Enter the provider's Access Token URL, together with the Client ID and Client Secret for
your registered application.

Requesting an OAuth 2.0 token

The full list of parameters to request a new access token is as follows, depending on your
grant type.

Under Configure New Token, enter details about the token:

Token Name - The name you want to use for the token.

Grant Type - A dropdown list of options. This will depend on the API service
provider requirements.

Callback URL - The client application callback URL to redirect to after auth. This
must be registered with the API provider. If not provided, Postman will use a default
empty URL and try to extract the code or access token from it. If this doesn't work
for your API, you can use the following URL:
https://oauth.pstmn.io/v1/browser-callback

Authorize using browser - > If you are using the Postman desktop app, you
can enter your auth details in your web browser instead of in Postman by
selecting Authorize using browser. When using the Authorization code or
Implicit grant type, select this checkbox to set the Callback URL to return to
 Postman. If you opt to authorize using your browser, make sure pop-ups are
deactivated for the callback URL, otherwise it won't work.

Auth URL - The endpoint for the API provider authorization server, to retrieve the
auth code.

Access Token URL - The provider's authentication server, to exchange an

authorization code for an access token.

Client ID - The ID for your client application registered with the API provider.

Client Secret - The client secret given to you by the API provider.

Scope - The scope of access you are requesting, which may include multiple
space-separated values.

State - An opaque value to prevent cross-site request forgery.

Client Authentication - Send a Basic Auth request in the header, or client

credentials in the request body. After upgrading to a new version, change the value
here to avoid problems with client authentication.

Select Advanced Options to customize the token:

Refresh Token URL - The endpoint for the refresh server, to exchange the refresh
token for an access token. If empty, the refresh token URL will be the same as the
access token URL.

Auth Request, Token Request, and Refresh Request - Define any custom
parameters you want to send with auth requests, token requests, or refresh
 requests. For each key-value pair you define, select an option to send the
parameter in the request body, request URL, or request headers.

If you add multiple keys with same key name, they will be sent with the
request as an array.

If you added resource or audience URIs in a previous version of Postman, you

can import them as custom parameters. Select the Audience and Resource tab
to review the resources and audiences, then select Move Audience and
Resource. For all grant types except implicit, the parameters are added to the
token request. For implicit grant types, the parameters are added to the auth
request.

When the configuration is complete, select Get New Access Token. The configuration
information is saved along with the access token and will be used every time the token is
refreshed.

When you use Authorization code or Implicit grant type, you will be prompted to
supply your credentials to retrieve an access token to use in later requests. By
default Postman will display a pop-up window when you select Request Token. If
you are using the Postman desktop app, you can instead choose to authenticate
using your system's default web browser. Select Authorize using browser to set the
Callback URL to return to Postman after you complete auth in the browser, so that
your requests can use the token returned on successful authentication.

A token from the API includes its details, together with the expiry, and optionally a refresh
token you can use to retrieve a new access token when your current one expires. Select
Proceed and then select Use Token to use the returned token.
Any successfully retrieved tokens will be listed in the request Available Tokens dropdown
list. Select one to send with your request. Select Manage Tokens in the dropdown list to
view more details or delete your tokens.

If authentication fails or times out, Postman will display an error message. You can check
the error details in the console, Retry to try authentication again, or edit your auth details
before continuing.

Deleting a token in Postman doesn't revoke access. Only the server that issues the
token can revoke it.

Refreshing an OAuth 2.0 token

Before an OAuth 2.0 token generated in Postman expires, Postman automatically
refreshes it in the background before you send a request that uses it. The refreshed
access token is updated in any requests that it's used in. If you added any custom
parameters when generating the token, those parameters will also be used for the
refreshed token.

Auto-refreshing is the default behavior. To turn this feature off or on, select Auto-refresh
access token. To manually refresh a token, select Refresh. The token's expiration time
displays if the token expires within the next day.

Auto-refresh is available when a refresh token is present. If no refresh token is present, the
Auto-refresh access token toggle and the manual Refresh option aren't available. To check
if a refresh token is present, select Manage Tokens in the Token dropdown list. If a refresh
token is not present, check with the authorization service. Postman can't refresh the
access tokens without the refresh token.
 You can use auto-refresh when manually sending the request. Auto-refresh isn't
used for scheduled runs or monitors for the same collection.

Sharing an OAuth 2.0 access token

To enable other Postman users to view and use an OAuth 2.0 access token, select Share
access token.

To revoke other users' access to a synced token, do the following:

1. Turn Share access token off.

2. Select Remove Synced Token.

After you revoke access, other users with access to the request won't be able to see or
use the token.
Changing the OAuth 2.0 token type
Postman supports using access tokens or ID tokens for OAuth 2.0 authorization. An
access token enables an OAuth client to make calls to an API. An ID token contains
information about the authenticated user. This information can be used by an OAuth client
to customize their experience.

If an ID token is present, you can select the token type (Access token or ID token) in the
Use Token Type dropdown list. If no ID token is present, this dropdown list isn't available.
To check if an ID token is present, select Manage Tokens in the Token dropdown list.

Hawk authentication
Hawk authentication enables you to authorize requests using partial cryptographic
verification.

To use Hawk authentication, do the following:

 1. In the Authorization tab for a request, select Hawk Authentication from the Type
dropdown list.

2. Enter your details in the Hawk Auth ID, Hawk Auth Key, and Algorithm fields. You
can optionally set advanced details, but Postman will try to generate values for
them if necessary.

When the required details are complete in the Authorization tab for your request,
Postman will add them to the Headers.

The Hawk Authentication parameters are as follows:

Hawk Auth ID - Your API authentication ID value.

Hawk Auth Key - Your API authentication key value.

Algorithm - The hash algorithm used to create the message authentication code
(MAC).

Advanced parameters:

User - The username.

Nonce - A random string generated by the client.

ext - Any application-specific information to be sent with the request.

app - The binding between credentials and the application to prevent an

attacker using credentials issued to someone else.
 dlg - The ID of the application the credentials were issued to.

Timestamp - Timestamp the server uses to prevent replay attacks outside the
time window.

AWS Signature
AWS is the authorization workflow for Amazon Web Services requests. AWS uses a
custom HTTP scheme based on a keyed-HMAC (Hash Message Authentication Code) for
authentication.

The official AWS Signature documentation provides more detail:

Signing and Authenticating REST Requests

Use Postman to Call an API

To use AWS Signature, do the following:

1. In the Authorization tab for a request, select AWS Signature from the Type
dropdown list.

2. Select the location where Postman will append your AWS auth details using the
Add authorization data to dropdown list, choosing the request headers or URL.

If you select Request Headers, Postman will add Authorization and X-

Amz- prefixed fields in the Headers tab.

If you select Request URL, Postman will add the auth details in Params with
keys prefixed X-Amz- .
 3. Enter your access key and secret values directly in the fields. For extra security,
you can use secret variables for these values.

4. You can optionally set advanced fields, but Postman will autogenerate these if
necessary.

The AWS Signature parameters are as follows:

AWS Region - The region receiving the request (defaults to us-east-1).

Service Name - The service receiving the request.

Session Token - Required only when using temporary security credentials.

NTLM authentication
Windows Challenge/Response (NTLM) is the authorization flow for the Windows operating
system and for standalone systems.

To use NTLM authentication, do the following:

1. In the Authorization tab for a request, select NTLM Authentication from the Type
dropdown list.

2. Enter your Username and Password for NTLM access (use variables to avoid
entering the values directly). You can optionally specify advanced parameters, but
Postman will try to autocomplete these if necessary. By default your request will run
a second time after extracting data received from the first. You can turn off this
behavior by selecting the checkbox.
Advanced parameters for NTLM auth are as follows:

Domain - The domain or host to authenticate against.

Workstation - The hostname of the PC.

Akamai EdgeGrid
Akamai EdgeGrid is an authorization helper developed and used by Akamai.

To use Akamai EdgeGrid, do the following:

1. In the Authorization tab for a request, select Akamai EdgeGrid from the Type
dropdown list.

2. Enter your Access Token, Client Token, and Client Secret, using variables for extra
security—you will receive these details when you register a client application with
Akamai.

When the required details are complete in the Authorization tab for your request,
Postman will add them to the Headers.

For information on obtaining your credentials, see Akamai Developer - Authorize your
Client.

Syncing cookies
If you have session cookies in your browser, you can sync them to Postman using the
Interceptor. See Interceptor extension and Cookies for more detail.